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 <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 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 Gainty <mgai...@hotmail.com> wrote:
>>
>//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<String,?> sharedState, Map<String,?>
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
><komme...@freemail.hu>
>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.
>
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
