Re: Propagation of Subject with JAAS and SecurityManager enabled
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í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 requests >org.apache.catalina.connector.Request object (and store it in the session >afterwards under Globals.SUBJECT_ATTR) >- org.apache.catalina.connector.Requests 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
Propagation of Subject with JAAS and SecurityManager enabled
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 requests org.apache.catalina.connector.Request object (and store it in the session afterwards under Globals.SUBJECT_ATTR) - org.apache.catalina.connector.Requests 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
Re: Propagation of Subject with JAAS and SecurityManager enabled
Thank you, Martin, for answering despite of the messed up email! A short point to clarify: I am using JAASRealm, and a custom jaas.config file which does not refer to AASMemoryLoginModule. So JAASMemoryLoginModule is also not called. As for my custom login module, I checked it, and it does use the same Subject that is passed to it upon initialize(...), it just adds Principals to it, so it shall be imho ok. My gut feeling still tells me that the current construct might not work, as it seems that the session (with the key Globals.SUBJECT_ATTR) is used for passing the Subject between different parts of the code - but at all the places where Globals.SUBJECT_ATTR is used to access the session, a new Subject is created, and put into the session under this key... Martin Gaintywrote: >> >//in org.apache.catalina.security.SecurityUtil subject comes from the session >here is code from execute: > > >// first argument is always the HttpServletRequest object > if (targetArguments != null && targetArguments[0] instanceof > HttpServletRequest){HttpServletRequest request = >(HttpServletRequest)targetArguments[0]; > boolean hasSubject = false; //get the session but dont create the session if > already invalidatedHttpSession session = > request.getSession(false);if (session != null){ > subject = > (Subject)session.getAttribute(Globals.SUBJECT_ATTR); > hasSubject = (subject != null);} //IF subject was null to > begin with AND//IF subject was not previously stored in session then create a > new Subjectif (subject == null){subject = > new Subject(); //if principal parameter is not null then add it to subject > if (principal != null){ subject.getPrincipals().add(principal);} } //store subject for further referenceif (session != null && !hasSubject) { session.setAttribute(Globals.SUBJECT_ATTR, subject);} } Subject.doAsPrivileged(subject, pea, null);//end SecurityUtil //org.apache.el.catalina.realm.JAASMemoryLoginModule.java://notice that it is responsibility of developer to pass in a valid subject to initialize method of JAASMemoryLoginModule public void initialize(Subject subject, CallbackHandler callbackHandler,Map sharedState, Map options) {log.debug("Init");// Save configuration values this.subject = subject; did you verify you are passing valid subject to initialize method of JAASMemoryLoginModule > ? >Martin >__ From: kommersz > >Sent: Wednesday, February 22, 2017 5:17 AM >To: users@tomcat.apache.org >Subject: Propagation of Subject with JAAS and SecurityManager enabled > >(noticed that my previous post on the same was somewhat garbled - reposting >reformatted) > >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 requests >org.apache.catalina.connector.Request object (and store it in the session >afterwards under Globals.SUBJECT_ATTR) >- org.apache.catalina.connector.Requests 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
Propagation of Subject with JAAS and SecurityManager enabled
(noticed that my previous post on the same was somewhat garbled - reposting reformatted) 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 P rincipal, which is extracted from the requests org.apache.catalina.connector.Request object (and store it in the session afterwards under Globals.SUBJECT_ATTR)- org.apache.catalina.connector.Requests 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
Propagation of Subject with JAAS and SecurityManager enabled
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 requests org.apache.catalina. connector.Request object (and store it in the session afterwards under Globals.SUBJECT_ATTR)- org.apache.catalina.connector.Requests 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 propagationIf 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