Jo, Thanks for the "hint".
I think that your comment, along with the section labelled "How can I access members of a custom Realm or Principal?" here: http://wiki.apache.org/jakarta-tomcat/HowTo might allow the Principal to be allowed. I can get to request.getUserPrincipal().getName(), but I haven't tried the "cast" yet. If that works, that would at least allow me to get to the credentials, etc. that get populated by the LoginModule, if need be. I guess the Subject is inaccessible directly though, but I think that's suppose to be the same as request.getRemoteUser if the user has been authenticated, right? Jim Jo wrote: > > Is casting request.getUserPrincipal() to your custome-made Principal gonna > help get what you want ? > > Jojada.- > > ----- Original Message ----- > From: "ohaya" <[EMAIL PROTECTED]> > To: "Tomcat Users List" <tomcat-user@jakarta.apache.org> > Sent: Tuesday, July 19, 2005 9:46 AM > Subject: Re: JAASRealm and Subject > > > 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] > > > > > > !DSPAM:42dc431c292681154681485! > > > > > > --------------------------------------------------------------------- > 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]
