> > > 
> > > Hi,
> > > 
> > > I didn't say anything about it before, but I've been, in parallel with 
> > > our discussion, mucking around both the OAM innards and the Apache source 
> > > code, as best I can, trying to find out why that internal remote_user 
> > > string (it is, I believe, only internal to Apache), to see why it isn't 
> > > being set.  Notice also that I said "remote_user string", rather than 
> > > "remote_user variable".
> > > 
> > > The reason is that, in looking through the Apache source code, I haven't 
> > > (yet) been able to find a variable like that.  Rather, it looks like the 
> > > Apache code just dumps the string representing the user into some buffer 
> > > that its building to send out via AJP protocol.
> > > 
> > > On the OAM side, I haven't been able to find any configuration "tweaks" 
> > > that would make their webagent populate (or not populate) whatever data 
> > > structure inside of Apache either.
> > > 
> > > I may or may not decide to try to bug Oracle about why their webagent 
> > > doesn't do appear to do that.  Probably not though, as in the past, it's 
> > > hard to find someone who knows their stuff well enough to answer such an 
> > > esoteric question.  Plus, the valve seems to work at the moment.
> > > 
> > > Having said that, and having started to work more with my valve code, I 
> > > do have a more on-topic question for you and for the list, in general.  
> > > 
> > > To recall, my test Tomcat is pretty much vanilla, including the default 
> > > realm that uses the tomcat-users.xml.
> > > 
> > > Earlier, you and Chuck said that when my valve code asserts a user into 
> > > Tomcat (e.g., via the setUserPrincipal()), that that asserted user didn't 
> > > have to even be in the Tomcat realm.
> > > 
> > > I'm finding that that part does work as we've discussed, but the question 
> > > that I have is what roles in Tomcat would that user have (in Tomcat)?  
> > > 
> > > In my testing, and as I've mucked around with my valve code, I found that 
> > > I could assert not only a user, but it looks like I can also assert that 
> > > user's roles in Tomcat.  
> > > 
> > > And, I can even assert roles that don't exist in the realm!!
> > > 
> > > In other words, suppose my valve gets a request with a userID of 
> > > "foobar".   Then, it appears that my valve code can not only assert the 
> > > "foobar" user into Tomcat, but can also assert that the "foobar" user has 
> > > roles "foobarRole1" and "foobarRole2", EVEN when those roles don't 
> > > exist/aren't defined in the Tomcat realm.
> > > 
> > > Is this correct?
> > > 
> > > 
> > > If it is, I may have a problem. 
> > > 
> > > Let me explain:
> > > 
> > > My original plan/thought/idea/thinking was that if I could get my valve 
> > > code to assert the user into Tomcat as a principal in the Tomcat 
> > > environment, then, at least to Tomcat itself, that user/principal would 
> > > "pick up" the roles that that user would have within the Tomcat realm.
> > > 
> > > In other words, if I asserted "foobar" into Tomcat, and if there was 
> > > already a user named "foobar" in the Tomcat realm, that then the asserted 
> > > user would have all of the roles within Tomcat that he/she should have, 
> > > via the realm.
> > > 
> > > However, that doesn't appear to be the case :(.  
> > > 
> > > Rather it appears that even if the user that I'm asserting actually 
> > > exists in the Tomcat realm, after my valve asserts the user into Tomcat, 
> > > the user doesn't appear to have any roles in Tomcat.  I'm using the 
> > > security example app in the /examples that comes with Tomcat to check if 
> > > Tomcat 'believes" that the asserted user has xxxx role.
> > > 
> > > In other words, even though my valve code can assert a user into Tomcat, 
> > > and even if that same user already exists in the Tomcat realm, the 
> > > asserted user seems to be 'disassociated' from the same user in the 
> > > Tomcat realm?  
> > > 
> > > I'm not sure if I'm explaining that clearly, but let me know?
> > > 
> > > Here's an example:
> > > 
> > > In tomcat-users.xml, I have a user, "0test" with role "manager-gui".
> > > 
> > > I send a header into my valve with userID "0test", and it asserts the 
> > > "0test" user into Tomcat.
> > > 
> > > Then I go to the Tomcat security example app, and I search for role of 
> > > "manager-gui", and the app tells me that user "0test" has not been 
> > > granted the "manager-gui" role.
> > > 
> > > So the question that I really have here is:  Can I "connect" the user 
> > > that my valve asserts into Tomcat with the corresponding user in the 
> > > Tomcat realm (so that the asserted user can "have" all of the roles in 
> > > Tomcat that he/she "should" have)?
> > > 
> > > Thanks,
> > > Jim
> > > 
> > >
> > 
> > 
> > Hi,
> > 
> > I just found the following, which seems to confirm what I'm finding with 
> > asserted users, as described above:
> > 
> > http://wiki.oss-watch.ac.uk/ShibbolethTomcatIntegration 
> > 
> > Note where it says:
> > 
> > "This requires that any acess to /jsp-examples/snp/* be authenticated to 
> > any of 
> > the roles declared to Tomcat elsewhere in the web.xml file. The problem 
> > with 
> > this when receiving authentication information from Apache httpd via mod_jk 
> > is 
> > that we have not found any way to associate role membership with the 
> > authenticated user. As a result, Tomcat refuses access to the servlet, even 
> > though we do appear to have successfully conveyed authenticated user 
> > information 
> > to Tomcat. 
> >  
> > It appears that when Tomcat's own authentication is bypassed (using 
> > tomcatAuthentication="false" noted above), Tomcat's mechanisms for 
> > assigning 
> > roles to users (e.g. from tomcat-users.xml) are also bypassed, so the 
> > authentication is effectively useless for invoking servlets." 
> > 
> > That is exactly the same problem/behavior that I'm seeing with users that I 
> > assert into Tomcat using my valve code...
> > 
> > Jim
> > 
> 
> P.S.  Also, the same problem/behavior occurs, even when I'm not using my 
> valve code to do the assertion, when I use mod_jk and AJP and 
> tomcatAuthentication=false.  In this case (using mod_jk and AJP), the user 
> that gets asserted into Tomcat via the AJP connector doesn't get any roles 
> within the Tomcat realm :(....
> 
> 


Hi,

In thinking about the role problem that I described above, I think that this 
kind of takes me back to my original question in this thread.

With other products that I've worked with (e.g., WebLogic) after the id is 
asserted, another, authentication provider will take the asserted id and then 
authenticate the id (into the WebLogic domain, in the case of WebLogic).

In the case here, with Tomcat, it seems like what I need to do to fix this 
roles problem is, in my valve code, to take the incoming pre-authenticated id, 
and somehow actually authenticate it into the existing Tomcat realm.

If you recall, that is kind of related to my first question in this thread, 
i.e., how can I take just the userID, with no additional credentials, and 
authenticate the user into the Tomcat realm?

Does anyone know how to do that in code?  Does Tomcat have an API that I can 
call in my valve code, something like:

xxxx.authenticate(myUserId);

??

Thanks,
Jim



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to