Well, if there are no hints, here is my view. I checked the code for locations where org.apache.catalina.Globals.SUBJECT_ATTR (or the String "javax.security.auth.subject") is used. There are seemingly two locations: - org.apache.catalina.connector.Request.setUserPrincipal(...) - org.apache.catalina.security.SecurityUtil.execute(...) the way they are using the SUBJECT_ATTR key to put a Subject in the Session practically excludes the possibility of using the Subject from the JAAS login module.
Beyond that, org.apache.catalina.realm.JAASRealm.authenticate(String username, CallbackHandler callbackHandler) does effectively throw away the Subject gained after having extracted the user and role for creating a GenericPrincipal - so even a workaround with passing the subject between the JAAS LoginModule and a Valve in ThreadContext to smuggle it into the Session under SUBJECT_ATTR would not work. I am new here, and do not know how things work, but beyond a few questions I would also make a proposal for a fix, and would be ready to deliver it if I get it approved :) So: - Is this intentional not to allow a Subject from a JAAS LoginModule to be used when switching to privileged mode using Subject.doAsPrivileged at a later point in the code? (I would doubt, but I may not know) - What is the purpose of putting the subject into the Session? As I understand (though haven't extensively studied), in JAAS a LoginModule has the responsibility to provide a Subject per request - so it could decide on its own if it wants to cache or not (though it does not have access to the Session) - would it be a good idea to remove the subject field from org.apache.catalina.connector.Request and move it into GenericPrincipal as a "reference to parent"? As the principal is reliably passed around, it could be used. Thanks, Gabor kommersz <komme...@freemail.hu> írta: >Hi, > >I am playing around with the following things: > - X.509 authentication >- Security Manager enabled >- Custom JAAS login module via JAASRealm > >My custom JAAS login module properly propagates a javax.security.auth.Subject >instance at commit() back. My aim is to use this javax.security.auth.Subject >as a basis for authorization checks - expect >org.apache.catalina.security.SecurityUtil to take this over. >Curiously, by the time it comes to >org.apache.catalina.security.SecurityUtil.execute(...) applying >Subject.doAsPrivileged, it is done with another javax.security.auth.Subject >instance. > >Having looked a bit into it what is happening, I see the followings >- org.apache.catalina.security.SecurityUtil.execute(...) looks for a subject >to be present in the session object with key Globals.SUBJECT_ATTR >("javax.security.auth.subject"). >- if it is not present, it will create a new blank Subject containing only one >Principal, which is extracted from the request's >org.apache.catalina.connector.Request object (and store it in the session >afterwards under Globals.SUBJECT_ATTR) >- org.apache.catalina.connector.Request's setUserPrincipal(Principal >principal) sets the session object with key Globals.SUBJECT_ATTR to a newly >initialized javax.security.auth.Subject with a single Principal. > >Summary: to me it seems that the mechanism currently used to propagate the >Subject to org.apache.catalina.security.SecurityUtil.execute(...) _always_ >creates a new empty Subject and adds a single user principal into it. > >Questions: >- do I miss something about Subject propagation? >If not: >- is this intentionally planned like this? >- would it not make sense to allow Subjects to be propagated to SecurityUtil >1:1 from JAAS Login modules to be used as the Subject for privileged execution? > >Btw, I am on 7.0.68, but seems that the relevant pieces of code has not been >changed by 7.0.75 - most recent version checked. > >Thank you for any help upfront! > >Regards, >Gabor > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org