Ok, Jim You are right in this point. It´s possible to get Principal but not Subject.
Rogerio ----- Original Message ----- From: "ohaya" <[EMAIL PROTECTED]> To: "Tomcat Users List" <tomcat-user@jakarta.apache.org> Sent: Tuesday, July 19, 2005 1:10 PM Subject: Re: JAASRealm and Subject > 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" <tomcat-user@jakarta.apache.org> > > 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" <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] > > > > > > > > > > > > > --------------------------------------------------------------------- > > 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]
