tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kommersz <komme...@freemail.hu>
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
"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 <kommersz@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


Mime
View raw message