"Using JAAS for Authorization & Authentication", by Dan Moore, explains how to use the Java Authentication and Authorization API (JAAS). It plugs JAAS into the Struts framework and shows how to use JAAS to secure resources in an MVC architecture; It will first examine the JAAS infrastructure and then look at integration with Struts.

Read Dan Moore's "Using JAAS for Authorization & Authentication"

  I didn't read the article throughly. However, it seems it does not make much sense if you cannot integrate to J2EE EJB container. Using it in this way, you have to maintain another security stuff align with EJB container.

  Zhou Wu

JAAS is part of J2EE 1.3, but there is not a whole lot of documentation on how this works with the application server. There is also the new Java Authorization Contract for Containers (Java ACC) for plugable security components in J2EE 1.4. I am glad there is going to be more choice when dealing with authorization, the J2EE 1.2 model was way to simple and constricting.
 

The water is too far for the current fire we have.

<Zhou Wu>
I didn't read the article throughly. However, it seems it does not make much sense if you cannot integrate to J2EE EJB container.
</Zhou Wu>

Perhaps you should've ;-) If you would, you'd see that it is definitely possible to integrate JAAS with EJB container. See JBoss custom login module that uses LDAP to authenticate JNDI lookups.

-- Igor

After reading the article I'm still not clear on how JAAS can provide security for the web tier. Constraints are defined in web.xml, then the user's role is determined by calling HttpServletRequest's "isUserInRole". Aside from using those methods, I'm not sure if Struts should have anything to do with security, which is the responsibility of the app server as configured in web.xml. Struts is just a particular implementation of servlets.

Is there information that answers just exactly how JAAS and "isUserInRole" are related?

Taylor

  Don't waste time on this if you can wait (J2EE 1.4 or for some J2EE 1.3 ).

Being that J2EE 1.4 is a LONG ways out (1.3 still doesn't addressed user management or standard security interfaces to the point to being useful), you might want to check out OSUser from OpenSymphony. It's a standard interface for user and group management and has hooks in to Orion, JBoss, WebLogic, Pramati, Tomcat, Resin, Jetty, and (coming soon) JRun.

Check it out at http://www.opensymphony.com

From how I understand it, JAAS would be an implementation of a Realm for your web container as opposed to say the Memory, JDBC, and JNDI realms tomcat ships with. The realm of course is what handles authentication and allows you to specify security in your web.xml file without having to write any code. It also handles isUserInRole and getUserPrincipal requests.

Therefore, instead of using the JDBC Realm implementation to have users authenticated against a SQL db, you could use a JAAS Realm implementation to have users authenticated against say Active Directory or a WinNT domain.

If I remember right, there is a JAAS Realm implementation in tomcat 4 but it isn't documented or mentioned at all.

Don

> cannot integrate to J2EE EJB container

I also have this problem. If the user has been authenticated by/in the web tier, say Tomcat (so that getUserPrincipal returns not null) -- how can this Principal be promoted to the EJB calls (so that getCallerPrincipal will return not null)? Are there some standard docking points or do we have to "manually" authenticate against the EJB container using its proprietary API?

--
al

I agree with Taylor. I'm not clear on the benefits of JAAS over Declarative Security in an MVC environment, including Struts.

I'm not sure how the declarative security model works on other containers, but on WLS using Struts, no security coding was necessary aside from the deployment descriptors defined in web.xml. All <security-constraints> were defined in web.xml, defining the appropriate roles that have access to the web application and sub-functions within the web application. Roles map to principals in weblogic.xml file.

If a user attempts to go to a link that is protected in the <security-contraints> definition, the user will be automatically routed to the login page to authenticate.

I'd like to understand the advantage of JAAS over Declarative security defined in your
web application's deployment descriptor (web.xml)-- see below.

..
..
<!-- ******************************************* -->
<!-- DECLARATIVE SECURITY DEFINITIONS -->
<!-- ******************************************* -->
.. entry into entire site...
<security-constraint>
   <web-resource-collection>
        <web-resource-name>yourApp</web-resource-name>
<url-pattern>/yourSite/*</url-pattern>
<http-method>GET</http-method>
<http-method>PUT</http-method>
    </web-resource-collection>
    <auth-constraint>
<role-name>UserRole</role-name>
<role-name>AdminRole</role-name>
    </auth-constraint>
</security-constraint>
..
..define other constraints on fine-grained parts of the site.
..
<!-- *********************************** -->
<!-- AUTHENTICATION -->
<!-- *********************************** -->
<login-config>
   <auth-method>FORM</auth-method>
   <realm-name>YourRealm</realm-name>
   <form-login-config>
<form-login-page>logon.jsp</form-login-page>
<form-error-page>logon.jsp?errors=true</form-error-page>
   </form-login-config>
</login-config>
<!-- ############################## -->
<!-- SECURITY ROLE ASSIGNMENTS -->
<!-- ############################## -->
<security-role>
   <role-name>UserRole</role-name>
</security-role>
<security-role>
   <role-name>AdminRole</role-name>
</security-role>
..
..



Thanks,
Liquid :~)

How can I get JAAS work with the declarative security model of the web tier? I want to set the security-constraints in the 'web.xml' and leave the login-config empty. Instead I have a custom login (LoginModule/CallbackHandler) using JAAS that should be used.
For the EJB tier this works fine, but I have no idea how to achieve this on the web tier.
BTW: how can I get the 'modified' sample application mentioned in the paper?

Tnx,
Carsten

Sample code is available at http://www.mooreds.com

Thanks everyone for your comments.

Dan

<quote>
I'd like to understand the advantage of JAAS over Declarative security defined in your web application's deployment descriptor (web.xml)-- see below.
</quote>

IMO, it's more like JAAS + declarative security defined in your web.xml. JAAS provides a standard API to "plug" some custom security real (e.g LDAP) into your app server, if access to that realm is not provided by the app server vendor.

The app will still use the declarative security definitions from web.xml (I hope) but user authentication and mapping of users to groups would come from the custom security realm.

--Igor

For me, the most telling comment comes in the final paragraph:

"...the reader will have noted the number of places where parts of the system need to be replaced to create a production system..."

When I looked at JAAS authorisation, it seemed impossible to produce a system that supports sophisticated and user-modifiable security policies without "replacing parts of the system".

For example, if you want to restrict access to data based on the "ownership" of that data, or based on whether a value falls within a particular range, then there is no way of avoiding extending/replacing the related JAAS parts. A similar issue arises if you want to store your security policy somewhere other than in a file. Given this, I wonder whether JAAS gives you enough additional "extras" to make its use worthwhile in applications that require a more complex security policy model.

I'd be curious to know, of the people using JAAS for authorisation, what are the things (if any) that you find yourselves replacing/extending and does it add up to a considerable amount of work?

Kieran

I don't uderstand how the web tier authentication can be propogated to the EJB container.
When a login module authenticates a user, the Login Context can now return a Subject. If this is all happening in a servlet in the web JVM, how does the application server know anything about this?

Please read the (J2EE, EJB, etc.) specs!!!. You didn't know because you didn't read.

I have read a lot about JAAS and found that it is not so useful in the real world since:

1. You must put the following code before the logic you want to protect.

Permission permission =
  new java.net.SocketPermission("localhost:8080", "connect");
AccessController.checkPermission(permission);

that means you must first make sure which part of you program needs to be protected. The implementation of the business logic tangled with the access control code.

2. If some of the method that hasn't been protected before, you can not impose the protection later without modifiy your source code.

Regards
Jerry

While this is good, I much prefer the way JBoss does it....using declaritive security in a web.xm/ejb.xml and using JAAS as the pluggable authentication module to achieve it. That way, you can customize how your users are authenticated and what roles they have while still using STANDARD calls like request.isUserInRole() or getCallerPrincipal(), making your business logic code separate from authentication/authorization mechanisms. If your authentiocation mechanism changes (say from database to LDAP) you can change it without modifying your business code. With some servers, you simply change an xml file (Orion/OC4J/BEA)to pint to your new JAAS/Authentication module and restart. Some don't even require a restart (JBoss I believe).

Doing things this way ensures code portablility, and doesn't require custom wrappers around the Subject (Auth class) residing in the session (that doesn't sound secure) or custom Permission classes.


This might be a good way to do things with Websphere, since it is notorious for not following specs exactly (I can't set per application authentication mechanisms in WAS, how stupid is that?):>

Mike

It seems that the Principal is set into the request and not the session. I could always create a filter to add it to the session, but I do not know why I have to add it to session, then add it back to the request each request just so I can keep the Principal alive.

Or am I doing something wrong? I thought I could just create the Principal, and that Pricipal lives, by ittself for the entire session?

very informative article about TSS golden age of hollywood actresses

will check TSS out for JAAS Authorization & Authentication buffalo brochure design