Re: Propagation of Subject with JAAS and SecurityManager enabled

[kommersz <ko...@freemail.hu>]

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 <ko...@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&#39;s org.apache.catalina.connector.Request object (and store it in the session afterwards under Globals.SUBJECT_ATTR)
>- org.apache.catalina.connector.Request&#39;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-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
>
>


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