Skip to main content

Using Custom JAAS LoginModule(s) for Authentication in GlassFish

Posted by kumarjayanti on February 1, 2010 at 1:55 AM PST

Many users often ask the question :  Can i use a custom  JAAS Login Module instead of the Proprietary GlassFish Custom Realms for user authentication ?.

The JSR-196 Login Bridge Profile allows a Server Authentication Module (SAM) to delegate some security processing to JAAS LoginModules. My  team member sudarsan has created a nice blog-post  on this with a sample netbeans  project showing the use of the Login Bridge Profile.  The sample can be plugged in as a ServerAuthentication Module for a webapplication on both GlassFish V2.X and V3.

GlassFish  includes implementations of a number of HTTP layer authentication mechanisms such as Basic, Form, and Digest authentication. JSR-196 support in GlassFish  allows developers to implement and configure new authentication mechanisms or make alternative implementations of the provided ones. The following tech-tip provides all the details for doing this.

So to answer the question at the top, if you have a SAM that implements an Authentication Mechanism (say BASIC), then you can use the Login Bridge Profile to configure a JAAS LoginModule in GlassFish that will be invoked by the SAM. The JAAS Login Module can then perform custom username-password authentication and communicate the resulting  Principal and Group information to GlassFish by making use of standard JSR-196 defined callbacks (which are supported by the GlassFish CallbackHandler supplied to the SAM as an argument).  

The important thing to note is that the LoginModule and the CallbackHandler (if any that the LoginModule uses) need  not have any proprietary Glassfish Code. In other words the JAAS LoginModule is suitable for use with other containers as well.  And if the Non-Glassfish Container supports JSR-196 then the developer essentially is freed from the task of figuring out how to set the Principal and Group information into the target Container, the JSR-196 CallbackHandler supplied by the Container would handle it for the user. 

This is in contrast to the Realm which is a proprietary GlassFish artifact. Though the Realm in GlassFish essentially makes use of  a corresponding LoginModule to do its authentication, it requires use of Glassfish specific code to ensure it communicates the Principal and Group membership information to the container in the right manner.

Related Topics >>

Comments

Hi, excuse me for my bad english, (Speak french) When I ...

Hi, excuse me for my bad english, (Speak french)

When I execute this instruction :

Subject subject = Subject.getSubject( AccessController.getContext());

I get null subject, I am under glassfish 3 with security manager enabled. and I have also

System.getSecurityManager() null;

I don't understand why I got System.getSecurityManager()= null (security manager enabled) and subject=null;

Thank you.

Any chance you could update the links. They don't work any more.

Any chance you could update the links. They don't work any more.

Form Authentication With SAM

Mate Thx For your post and i have read all the documentation in sudarsan's blog but i would like to ask you a question...if i do not understand wrong, SAM authenticates users...And i used tagishuath.jar for developing my own SAM based on DBLoginModule...However still can't understand how to use form authentication instead of basic authentication scheme...One more thing which i could not understand is do i still need to implement a Custom Realm for getting username and password of the user from form? May be the actual question should be what is the difference between realm and SAM and interaction between them(if any exists)? Thx for your advices in advance...

Hi,  If you want to use FORM

Hi,

 If you want to use FORM auth with the SAM, you will have to write code for that.  Once you implement FORM based auth in the SAM then you do not need any custom realm. From a spec point of view the SAM and Realm do not know about each other (no-relation).   A Realm is more like a backend database abstraction and provides primarily authentication. A SAM provides a way to extend the authentication mechanism defined by the container. So one can write a SAM to implement let's say OpenID authentication, whereas J2EE only defines BASIC, FORM, DIGEST.

 

Hope that helps.

 

How to use a FORM auth with the SAM

Hi. For me not at all :-) Could you pls post a sample on how to use FORM auth with the SAM? I've implemented a SAM using BASIC auth - that works fine (also with a custom LoginModul to authorize against a custom "server"). But now i need to "redirect" the request / SAM to a custom FORM... Thx a lot. Heico

How to use a FORM auth with SAM

Unfortunately we will have to write one, we don't have it. But some of the base functionality required, such as ability to read authentication headers was part of the code that implements the BASIC auth. If you ever endup writing one let me know.  Are you convinced that your usecase needs a SAM that supports FORM, otherwise you can always fallback to the default container supported FORM login (NO SAM) with a custom realm of your's.

How to use a FORM auth with SAM

No, i do not need a SAM that supports FORM. The only thing i need is a custom JAAS-LoginModul within my WEB-APP and FORM-based. My userdata are stored on a proprietary server (so i could not use the default Realms such ldap,...). I tried to use the Realm-mechanism of GF (implementing the AppservPasswordLoginModul) as described for GFv2. But it does not work for V3 - the jars (appserv-rt, appserv-ext) are not available in GFv3. So i started to use the SAM because i thought it would solve my problem :-) It solves, but there i am not able to implement the sam with a custom form ...

you could place a jar called

you could place a jar called security.jar in your classpath and it should work. you could also use appserv-rt.jar and appserv-ext.jar which is present in appserver/lib directory but use of those jar requires that you access them from within a glassfish installation, if you just copy those jars elsewhere and try to put them in classpath it wont work. Becuase those jars now have manifest classpath entries which point to the actual GFV3 OSGI jars which are present in modules directory.

 

Implemented yet

Has this FORM based authentication example been implemented yet?