Matt RaibleMatt Raible is a Web Developer and Java Champion. Connect with him on LinkedIn.

The Angular Mini-Book The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

Using JAAS and making it switchable

Erik Hatcher has convinced me that I need to give more coverage to JAAS in my chapter on Security. To quote his comment from yesterday's JAAS post:

I think you are underestimating the value of JAAS a fair bit. Suppose you want to authenticate your users against a database table of users/passwords. Without JAAS this is container-specific (sure it works nice in Tomcat, but would you be able to do FORM authentication in WebSphere easily?). We use JAAS in the big application I'm developing and it gives us the freedom to more easily port our application to other containers. What if your application needed to authenticate users (suppose for a portal, not that far fetched, eh?) where each "portlet" had a different authentication scheme: LDAP, Windows NT, database, etc. JAAS is the way to go.

While I can see Erik's point, I think that if the app servers follow the Servlet spec, implementing form-based authentication on any J2EE-compliant server should be easy. After all, Tomcat is the Reference Implementation. At the same time, the bit about the portles is a whole other can of worms - I can see what he's getting at, and I guess I need to figure out an easy way to demonstrate using JAAS. From what I understand, you do have to call the authenticate() in a servlet or filter. Hopefully, I can use a little Ant/XDoclet magic to create a sample that can switch b/w form-based, container-managed authentication and JAAS. Tell me what you think of this idea:

  • Use Ant and a task that runs if ${enable.jaas} is true
  • This task (i.e. jaas) will add a JAAS policy file to the webapp, maybe in the WEB-INF/classes directory so it's in the classpath
  • The jaas task will do some token replacement in login.jsp to change the form's action from j_security_check to something else. Ideally, I wouldn't have to do this.
  • The webdoclet task with not merge the web-security.xml file into web.xml
  • The ActionFilter, which I currently use to retrieve the user's information, will call the authenticate method and route appropriately if JAAS is enabled.

One thing I really like about form-based authentication (besides the ease of setup and no required programming) is that it allows users to bookmark pages in your app. When they select that bookmark again after logging out, they are prompted for a login and routed to the bookmark upon successful authentication. I hope JAAS can do this too.

Posted in General at Dec 05 2002, 04:22:22 AM MST 5 Comments
Comments:

Matt, I very far from being an expert with JAAS and J2EE security, but I think you've got several things fishy in the items you listed. The JAAS configuration is *outside* of your application, so it doesn't make sense to configure it within WEB-INF/classes (please correct me if I'm wrong with anything I say here). JAAS works *with* J2EE security, using j_security_check and such. The container handles it smoothly under the covers automatically. But interestingly, you mention toggling things in web-security.xml for XDoclet merging. Well, here ya go... we do this in order to toggle between FORM and BASIC authentication. In Ant we have this: <deploymentdescriptor validatexml="true" distributable="false"> <configParam name="security" value="${web.security.mode}"/> </deploymentdescriptor> And web-security.xml looks like this: (note, its perfectly legal to use XDoclet tags in merge files!) <XDtConfig:ifConfigParamEquals paramName="security" value="basic"> <login-config> <auth-method>BASIC</auth-method> <l/ogin-config> </XDtConfig:ifConfigParamEquals> <XDtConfig:ifConfigParamEquals paramName="security" value="form"> <login-config> <auth-method>FORM</auth-method> <realm-name>java:/jaas/alumni</realm-name> <form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/login_fail.html</form-error-page> </form-login-config> </login-config> </XDtConfig:ifConfigParamEquals> I get the feeling you are going about this the hard way. If you stick to pure J2EE security, using JAAS to spell out what to authenticate against and then simply deal with roles in web.xml to control URL's, and use the proper @tags on stateless session beans to control access to those (assuming you're using XDoclet) then you've got instant course granular security. There are of course situations where you need programatic security, or more "instance-based" security and that is an entire other issue, but still leverages J2EE security and the Principal associated with the session. I hope this at least helps be food for thought, even if its not entirely technically accurate! :) Erik

Posted by Erik Hatcher on December 05, 2002 at 12:11 PM MST #

So what you're saying is that, from a developer's perspective - they don't really care about JAAS. It goes back to my original perception, that app servers use JAAS under the covers. The interesting thing in your comment is the realm name <code>java:/jaas/alumni</code> - this must be configured in your app server. Did you have to do any custom coding to implement JAAS based security, or just create a JNDI entry?

Posted by Matt Raible on December 05, 2002 at 12:47 PM MST #

I found this example of how to integrate JAAS with BASIC authentication. I think I'll alter it to work with FORM-based authentication and call that good.

Posted by Matt Raible on December 05, 2002 at 01:02 PM MST #

In web app you can have several protection domains ( "realms" ) which are mapped to different URLs, you have to map login configuration to realms somehow - so similarity with JNDI name is not intendet :) Then there are "login configurations" for the JAAS - that's where all diferent login modules are defined & configured. In your client application to provide login you must do following: 1. Create login context: try { _lc = new LoginContext( "other", new LoginCallbackHandler() ); } catch( LoginException ex ) { ex.printStackTrace(); } "other" is configuration name, and this configuration is defined in auth.conf of my application LoginCallbackHandler is a class which will provide JAAS with principal/credential on demand - in my case it will just getText() from some text fields. 2. When I'm ready to login: _lc.login(); Callbacks are asked, strings are pulled from text fields and fed to login module ( which authenticates you, and maps user roles to principal , and then stores them that they can be found later ) I do not do any checks, because module in question is just dummy and only stores data for EJB invocations. Well, JAAS is a bit obscure ( and har do explain ) but it's possible to master it...

Posted by Konstantin Pribluda on December 05, 2002 at 01:10 PM MST #

Exactly, JAAS is configured in application server or web caontainer ( or both ) - this is outside of scope of xdoclet or your application. You just say that: "if you like to call this method or access this URL you have to be inn that role" - container does everything for you then. Realm name can be everything you like - it does not haveanything to do with JNDI names or whatever. JBoss happens to map security contexts to JNDI - but normally you do not have to be concerned with them. All I have to enab le JAAS is: 1. Configure security in JBoss ( no JNDI involved :) ) 2. Create auth.conf for my application ( no JNDI involved ) 3. Obtain JAAS login context , feed my callabck handler to them - in swing it just pulls username/password out of text fields, in Tomcat it used to pull from session variables ( values were deposited by j_security_check interceptor ) There is no magic :)

Posted by Konstantin Pribluda on December 06, 2002 at 03:50 AM MST #

Post a Comment:
  • HTML Syntax: Allowed