Rogerio, Re. Jo's message: I didn't interpret his message to mean that you could access the Subject, but rather, I think that he was suggesting that you could access the Principal using request.getUserPrincipal(), and then you could do something like casting the object returned by the getUserPrincipal() to gain access to the Principal object.
Jim Rogerio Baldini das Neves wrote: > > Jim, > > First of all, thanks so much for your help. > > I have got same conclusions. > Your Subject is inaccessible directly in your web application, using jaas > realm in tomcat . > You must use request.getRemoteUser and request.isUserInRole. > I think that is impossible to access the list of user´s roles. > > In another way, you can create a form that implements your logon and calls > your LoginModule, putting Subject in user session. > So, in your application, you can access Subject from this session. > > I don´t know you, but I prefer the first choice. > It´s more "beautiful". > > And refering to Jo´s message, I don´t believe that it works. > Principals can´t be cast to Subject. They are not related. > But I am not 100% sure about that. > > Thank you again. > Rogerio > > ----- Original Message ----- > From: "ohaya" <[EMAIL PROTECTED]> > To: "Tomcat Users List" <[email protected]> > Sent: Monday, July 18, 2005 10:14 PM > Subject: Re: JAASRealm and Subject > > > 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" <[email protected]> > > > 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] > > > > > > > > --------------------------------------------------------------------- > 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]
