Authentication in Glassfish

Followups for this post

Authentication in Glassfish revisited - JSR-196

Posted on December 30th, 2007

II've recently started to work on some "real-life" projects in J2EE... All done using Netbeans and Glassfish!! And there is one thing which is usually kind of overlooked while planning an application... That is "easy" authentication!!

This might be setting a cookie to remember the user for next time or having links with one-time tickets sent by e-mail...

Now... This is of course pretty easy to do... Unless of course u still wanna use the container managed authentication/authorization!!

J2EE uses JAAS for authentication... U need a realm to authenticate against and an authenticator which will get some credentials and passes them to the realm!! HTTP-Basic authentication will respond to requests with the appropriate http-code and wit for the browser to come back with username and password, then it will pass these values to a realm configured in the app-server and either let u in or not!!

As with most things in J2EE realms can be created to use any kind of data u might want... LDAP, SQL, a web-service... And this works fine for most cases!!

But... There is one drawback... The Authenticators included only allow for specific credentials!! Either username and password, or a client-certificate...

So... What can we do about our ticket-based login?? We have to create a custom Authenticator... And then we have to make this actually usable!!

The first step is rather straight-forward... Look at the Authenticators which are included in the Glassfish source and create one that behaves like we want it to!! I will try to talk about this in some later blog-entry, with some examples!!

The tricky part is making Glassfish actually "like" our new Authenticator, you will need to do:

add public static String MY_AUTHENTICATION = "MYAUTH";to
appserv-commons/src/java/com/sun/enterprise/deployment/web/LoginConfiguration.java
add && !LoginConfiguration.MY_AUTHENTICATION.equals(authenticationMethod)
to appserv-commons/src/java/com/sun/enterprise/deployment/LoginConfigurationImpl.java
add MYAUTH=my.custom.Authenticator
to appserv-webtier/src/java/org/apache/catalina/startup/Authenticators.properties

update appserv-rt.jar with:

zip &lt;glassfish-root&gt;/lib/appserv-rt.jar 
    com/sun/enterprise/deployment/LoginConfigurationImpl.class 
    com/sun/enterprise/deployment/web/LoginConfiguration.class

and

zip &lt;glassfish-root&gt;/lib/appserv-rt.jar 
    org/apache/catalina/startup/Authenticators.properties

copy the JAR containing your Authenticator to <glassfish-root>/lib/

Replace my.custom.Authenticator with the real class and adjust the names to ur liking!! :-)

Thats about it for now!!
:-)

glassfish and JSR 196

Submitted by Ron Monzillo (not verified) on Wed, 01/16/2008 - 16:39.

Aike,

You have described the process of creating and integrating a new (Tomcat derived) Authenticator Valve in Glassfish.

Glassfish is the RI for JSR 196. JSR 196 defines an SPI which extends the concepts of JAAS such that they can be applied to the authentication of network messages. The spec defines profiles which establish contracts for the use of the SPI in specific contexts. The first profile defined in the spec is called the Servlet Container profile. It defines a contract which allows for the integration of server authentication modules within a Servlet security constraint processing runtime. The contract also makes it possible for you to replace the system used to configure authentication modules; but you need not do that.

The spec and its associated javadocs may be found at: JSR 96

Glassfish is a compatible implementation of the Servlet Container Profile, and the SPI is also employed (via the SOAP profile as defined in the spec) by the Glassfish Metro stack. The Metro stack uses the SPI to integrate ws-security functionality, and to facilitate pluggability of the web services security mechanism.

You can see a sample ServerAuthModule (for use in the Servlet container) at:
SPNEGO SAM and I am working on making more samples (e.g., an OpenID SAM) available for people to try out. Also the SPI is planned for inclusion in EE 6.0.

Regarding its use in Servlet, the SPI defines a subject based contract; which allows the auth module to return more than just a single principal, and to do so without reliance on proprietary apis. The contract also defines callbacks that allow the SAM to distinguish the "user" principal among those in the returned subject and to establish group principals in a form understood by the authorization system. The contract also requires that the SAM be called independent of whether a session has already been established; which makes it possible for the SAM to manage sessions (if it chooses).

I will breifly outline the steps for integrating a new auth mechanism in the Glassfish Servlet container.

write a ServerAuthModule (i.e., a SAM) which mostly boils down to implementing the following method:
```
AuthStatus validateRequest(MessageInfo messageInfo,
                           javax.security.auth.Subject clientSubject,
                           javax.security.auth.Subject serviceSubject)
                           throws AuthException
```
The Servlet Container Profile; defines what will be passed to the SAM via messageInfo (i.e., the HttpServletRequest, HttpServletResponse, and a Map of property values)
package your SAM in a jar, and place your jar in the glassfish lib directory.
configure the SAM for use with your application. This is done in 2 steps. 1) Define your SAM as a message-security-provider in domain.xml (see the example in
To create an JSR196 httpservlet provider). 2) Bind the SAM for use with your application. You can do this by defining the httpservlet-security-provider attribute in the sun-web-app.xml of your app. Set the value of the attribute to the name you assigned to your SAM in step 1.

that should do it.
Ron
ps: I described how you can use one of the config systems that is bundled with Glassfish to configure your SAM for use with your application. You can also use JSR 196 to replace that config system and thereby change the way the SAM would be configured for use by the Glassfish Servlet container runtime.