Rogerio, Try taking a look at this page:
http://www.kopz.org/public/documents/tomcat/jaasintomcat.html I read through this awhile ago, but as I was just re-reading it for maybe the 10th time, I think that I'm starting to "see the light" and understand what the page's author (Michiel Toneman) was trying to say, and the problem (with JAAS and Tomcat) that he was trying to describe and work around. In the 1st paragraph, he says: "This is because the principals are used to denote the concepts of "user" and "role", and are no longer available in the security context in which the webapp is executed. The result of the authentication is available only through request.getRemoteUser() and request.isUserInRole()." I think that what he is trying to say is that when you use JAAS "normally" with Tomcat (e.g., configure a JAASRealm), the only artifacts from the LoginModule that servlets and JSPs have access to are the "user" (via request.getRemoteUser()) and the user's roles (via calls to request.isUserInRole()). Putting it another way, I think that the author is saying that your JSPs and servlets under Tomcat simply cannot access things like the Subject, the Principals, etc. So, this page is about his proposed workaround for this. From what I can tell, the way that he does this is that he has a SecurityFilter, which gets invoked BEFORE the LoginModule, and this SecurityFilter populates the Subject into the HTTP session before creating the context and invoking the LoginModule. In other words, this SecurityFilter kind of wedges itself between Tomcat and the LoginModule, I think, and by doing that, the Subject, etc. are now no longer "lost" to being accessed by servlets/JSPs. If you have a chance, please take a look at the above link, and see if you read this page the same way that I do? Comments from anyone else would be greatly appreciated, as I am very curious about this. It's not so much that I can't seem to access the Subject, but it seems like with the Tomcat environment, any work that the LoginModule does to populate the Principals, etc. seems to be totally inaccessible to servlets and JSPs? Thanks, and apologies for the longish message... Jim ohaya wrote: > > Hi, > > I'm not 100% sure if this is applicable, but I just found this: > > "Due to a design oversight in the JAAS 1.0, > javax.security.auth.Subject.getSubject() does not return the Subject > associated with the thread of execution inside a > java.security.AccessController.doPrivileged() code block. This can > present a inconsistent behavior that is problematic and causes > undesirable effort. com.ibm.websphere.security.auth.WSSubject provides > a work around to associate Subject to thread of execution. > com.ibm.websphere.security.auth.WSSubject extends the JAAS > authorization model to J2EE resources." > > in this thread: > > http://groups-beta.google.com/group/comp.lang.java.security/browse_thread/thread/3fbba23648cfb556/b736a3b0f27fc170?q=get+subject+loginmodule&rnum=21#b736a3b0f27fc170 > > If the above is applicable, then I don't know what the equivalent > workaround would be for Tomcat? > > Jim > > ohaya wrote: > > > > Rogerio, > > > > I've been wrestling with this exact same problem, but haven't had any > > more success than you have had thus far, so if you find out the answer > > to this, can you please post a msg here? I'll do the same... > > > > Thanks, > > Jim > > > > Rogerio Baldini das Neves wrote: > > > > > > Hi! > > > > > > I'm using the Tomcat 5 JAASRealm for authenticating users with my own > > > LoginModule. > > > In my LoginModule I am populating the Subject object delivered by the > > > Realm with Principals, Role Principals and Credentials. > > > > > > The authentication and the mapping of my user defined roles to tomcat > > > roles work fine, but I can´t get a reference to the Subject object in > > > my servlets. > > > > > > I have tried: > > > > > > AccessControlContext context = AccessController.getContext(); > > > Subject subject = Subject.getSubject(context); > > > > > > But it´s not working... subject = null; > > > > > > Can anybody help me, please ? > > > > > > Rogerio. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
