In this article, Frank Teti shows us how to architect for RBAC within an environment centered on J2EE using a TAI.
- Posted by: Regina Lynch
- Posted on: October 18 2005 11:40 EDT
J2EE security is still all about application-bound authorization and authentication not perimeter security. However, in a highly distributed J2EE architecture, the evolving Java 2 Security “Sandbox Model”, including Java Authentication and Authorization Service (JAAS) 1.0 plus vendor extensions is essentially a ubiquitous, enterprise-wide security model.
The power of JAAS is in its ability to use almost any underlying security system, such as, the local operating system, LDAP, RACF or Oblix NetPoint. Increasingly, one of the more popular alternatives is to use a Trust Association Interceptor (TAI). A TAI provides support to J2EE resources for role-based access and user-based single sign-on and is becoming one of the more popular alternatives.
Read "The Power of JAAS: Security System Alternatives"
- All that JAAS: Security System Alternatives by Andrew Clifford on October 18 2005 19:04 EDT
- Article: The Power of JAAS: Security System Alternatives by diabolo512 diabolo512 on October 19 2005 04:34 EDT
- Where's the "Printer Friendly Version" gone? by Neil Bartlett on October 19 2005 04:55 EDT
- Missunderstanding by Pavel Tavoda on October 19 2005 09:00 EDT
- Enterprise-wide security by Frank Teti on October 19 2005 14:03 EDT
- Article: The Power of JAAS: Security System Alternatives by Pete L on October 19 2005 14:34 EDT
- Using JAAS with JSF by Ed Burns on October 21 2005 12:10 EDT
- Nothing but nonsense and misconceptions by paul ilechko on October 24 2005 20:37 EDT
Although application security remains a programmatic area where creativity seems to rule the day, letting programmers proceed with their own application security constructs is always an option. Again, based on a discussion I had at the CIO Forum, some IT managers believe that application security beyond SSO should be left up to the individual devices of the application developers.
Much the same can be accomplished with Acegi for Springframework. (http://acegisecurity.sourceforge.net). JAAS, SSO, RBAC. Managers do not need to let developers start from scratch.
JAAS didn't fit the bill for us and we weren't keen to write lots of glue code to make it work for our distributed web app. Instead, we settled on Acegi (now in production at a very large financial institution) and have been very pleased with it thus far.
Note that I recently added a Siteminder authentication extension (also in our production environment) into Acegi's CVS tree. See http://acegisecurity.sourceforge.net/ for more info.
We did not use JAAS or Acegi but another team had build the security mechanism from scratch for single signon on LDAP.
Not only was it time consuming, it has limitation that it works only for struts!!
Acegi looks interesting but does it also work only with Spring or can be used for any web application ?
"Acegi Security relies on the Spring IoC container to wire its classes, and execute lifecycle methods such as afterPropertiesSet(). Some Acegi Security classes also publish events to the ApplicationContext, although you could provide a mock implementation of ApplicationContext easily enough which no-ops the method. In other words, if you particularly didn't want Spring in your application, you could avoid its use by writing equivalent getter, setter and lifecycle invocation processes in standard Java code. This is a natural consequence of the Spring way of development, which emphasises framework independence (it is not because we think there are good reasons people would not use Spring)."
More @ http://acegisecurity.sourceforge.net/standalone.html.
Like andrew, I believe that everything can be done with acegi. Furthermore, with the release of the version 1.0 next December, acegi will be even more powerful and stable.
However, there is also kasai which is not bad
you should look towards jGuard (http://jguard.sourceforge.net) which enable easy JAAS integration with j2ee platforms.
Developers many times misunderstand JAAS. Any framework mentioned in discusion could be based on JAAS or at least at some subpart of it. JAAS in core is couple of classes and interfaces. Rest is default implementation for many systems.
Last year we deployed application in BEA server with login/password authentication against MS AD. This year authorisation via SPNEGO was intoroduced in 8.1 SP4. Then we reinstalled server to new version and deployed Windows SSO withoud changing line of code.
Custom security solutions I see very often. However I guess JAAS provide enough ground for everybody to start with.
In large, corporate, heterogeneous environments (i.e. wintel, mainframe, unix, etc.) you need a security system that can be enabled in (IIS, Apache, J2EE, Notes, etc.) for enterprise-wide access control. Only systems like Oblix, Netegrity, etc. provide that kind of support. They also provide provisioning to LDAP, AD, etc., which is part of the security equation.
Only systems like Oblix, Netegrity, etc. provide that kind of support.
Here is one for the "etc" group. Check out CAS. Acegi provides an out-of-box adapter for it.
Acegi as CAS Client
CAS and JSR-168
ColdFusion client script
Seraph as CAS Client
Yale CAS client distribution
and Tivoli AM/WebSEAL
Just wanted to recommend RSA ClearTrust as an enterprise access managemnet/security framework. I am slightly biased, as I have been a product consultant for RSA Security but it's list of integration and feature specs is enormous.
What Frank Teti calls TAI (Trust Association Interceptor) is called an Agent in ClearTrust talk, and they are availble for basically every single web / app server you can think of. Like:
IBM HTTPD etc etc etc
You can declaratively in the ClearTrust GUI protect JMS queues, EJBs, servlets etc etc or use URL based protection.
For authentication you can choose between 6-7 already implemented authentication mechanisms or use the authentication broker framework to write your own.
ClearTrust handles about six or seven different types of LDAP and SQL user repository types.
It also has a very long list of enterprise applications it can provide SSO to such as Siebel and SAP etc.
In huge organisations, not all applications are in Struts, or in Spring or even in Java.... This is a really nice way to tie them all together and provide SSO between them (also handles different cookie domains of course).
Buuut... Of course the product costs money :)
In article it was already stated that:
TAI is used to connect reverse proxies, such as IBM WebSeal or Oblix NetPoint (recently acquired by Oracle) to a J2EE application server
We have used JAAS to customize our security login with WebSphere 5.1.2. I had the need to get some more information about the user from LDAP like: first & last name prefered language, etc.
So we had our own login module developed and chained after original websphere modules. It works great!
I've just posted an article on Using JAAS with JSF. I'd like to see if the TSS crowd things this is a good approach.
Ed (JSF co-spec lead)
This article is chock full of errors, although it's sometimes hard to tell what is accurate and what isn't, as it's so poorly written. Anyway, a few points:
"However, the article did not discuss, in detail, alternatives to using LDAP directly for Java Authentication and Authorization Service (JAAS) security"
- what exactly is this supposed to mean? LDAP has nothing to do with JAAS, so why should there be an alternative to using LDAP for JAAS? This is nonsense.
"A TAI allows for single sign-on (SSO) and management privileges within J2EE resources: for example, authentication, authorization and policy-based security"
- Umm, no, it doesn't. A TAI (which, by the way, is an IBM proprietary interface despite the fact that the article leads you to believe it can be used with other servers) provide identity assertion. This can be used as part of an overall SSO strategy, but it does not in and of itself provide SSO, and it certainly does not provide authorization or policy-based security.
"The focus of this article is to understand how to architect for RBAC within an environment centered on J2EE using a TAI."
- That would be difficult, as the TAI has nothing to do with access control.
" security behavior is implemented using JAAS for object method level security"
- Not in WebSphere, it isn't. JAAS is only used in WebSphere for authentication, but as the TAI interface has nothing to do with JAAS, it's hard to see what point is being made here.
"JAAS is a feature included in most J2EE-compliant application servers and was mandated by the J2EE 1.3 Specification."
No, it wasn't. JAAS is part of J2SE, and much of it is really not all that relevant in a J2EE environment, and most of it is optional. Mr. Teti really ought to read the specification.
I could go on, but I'm sure you get the point by now. If anyone is interested in what is actually involved in writing a TAI for WebSphere Application Server, please see my paper here: http://www-128.ibm.com/developerworks/websphere/techjournal/0508_benantar/0508_benantar.html
Your article (paper) is informative, and some of the co-authors on it I know are good, I worked with Keyes for a couple of years on a DCE project.
To your points:
It is still my understanding that JAAS was mandated by J2EE 1.3 spec for compliant app servers.
I don’t state that TAI is part of JAAS and I have read the spec, it is a reverse proxy that allows 3rd party security systems, such as, Oblix, Netegrity's SiteMinder, etc. to as you say in the paper “authenticate the user and then simply inform WAS as to the end-user's identity.” Thus, AC requires identification of the subject.
The point I was making is that you can access this information directly in LDAP or through a TAI to a 3rd party security system (that might also be storing the information in LDAP). As I stated, this article represented an alternative to approach discussed in this article http://www.theserverside.com/articles/article.tss?l=LDAP.
In any case, after the Web authentication is complete in the TAI or normal Web authentication case using LDAP directly, WAS creates a JAAS Subject containing the user’s authentication information and an LTPA token.
As far as it being proprietary, I don’t believe TAI is as proprietary as, for example, LTPA; at least, a TAI is an interface that other 3rd party’s can implement to, that IMHO is not proprietary.
But I believe you are missing the fundamental point, I have described a viable reference architecture that uses WAS without IBM Tivoli to accomplish the same result.
If you have the time maybe you could also review these IBM related articles, too.