tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kommersz <>
Subject Re: Propagation of Subject with JAAS and SecurityManager enabled
Date Wed, 08 Mar 2017 11:27:44 GMT
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
"") is used. There are seemingly two locations:
- org.apache.catalina.connector.Request.setUserPrincipal(...)
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 :)
- 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.


kommersz <> írta:
>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 instance
at commit() back. My aim is to use this as a basis for authorization
checks - expect to take this over.
>Curiously, by the time it comes to
applying Subject.doAsPrivileged, it is done with another instance.
>Having looked a bit into it what is happening, I see the followings
>- looks for a subject to be present
in the session object with key Globals.SUBJECT_ATTR ("").
>- 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
with a single Principal. 
>Summary: to me it seems that the mechanism currently used to propagate the Subject to _always_ creates a new empty Subject
and adds a single user principal into it.
>- 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!
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message