Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Date: Wed, 8 Mar 2017 12:27:44 +0100 (CET)
From: kommersz <kommersz@freemail.hu>
Subject: Re: Propagation of Subject with JAAS and SecurityManager enabled
To: Tomcat Users List <users@tomcat.apache.org>
In-Reply-To: <freemail.20170224195148.90198.1@fmxmldata09.freemail.hu>
Message-ID: <freemail.20170308122744.81694.1@fmxmldata07.freemail.hu>
MIME-Version: 1.0
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
archived-at: Wed, 08 Mar 2017 11:27:57 -0000

Well, if there are no hints, here is my view.=0A=0AI checked the code for l=
ocations where org.apache.catalina.Globals.SUBJECT_ATTR (or the String "jav=
ax.security.auth.subject") is used. There are seemingly two locations:=0A- =
org.apache.catalina.connector.Request.setUserPrincipal(...)=0A- org.apache.=
catalina.security.SecurityUtil.execute(...)=0Athe way they are using the SU=
BJECT_ATTR key to put a Subject in the Session practically excludes the pos=
sibility of using the Subject from the JAAS login module.=0A=0ABeyond that,=
 org.apache.catalina.realm.JAASRealm.authenticate(String username, Callback=
Handler callbackHandler) does effectively throw away the Subject gained aft=
er 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.=0A=0AI am new here, and do not know how things work, but b=
eyond a few questions I would also make a proposal for a fix, and would be =
ready to deliver it if I get it approved :)=0ASo:=0A- Is this intentional n=
ot 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) =0A- What is the purpose of putting the=
 subject into the Session? As I understand (though haven't extensively stud=
ied), 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 (thoug=
h it does not have access to the Session)=0A- would it be a good idea to re=
move the subject field from org.apache.catalina.connector.Request and move =
it into GenericPrincipal as a "reference to parent"? As the principal is re=
liably passed around, it could be used.=0A=0AThanks,=0AGabor=0A=0Akommersz =
<kommersz@freemail.hu> =C3=ADrta:=0A>Hi,=0A>=0A>I am playing around with th=
e following things:=0A> - X.509 authentication=0A>- Security Manager enable=
d=0A>- Custom JAAS login module via JAASRealm=0A>=0A>My custom JAAS login m=
odule 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 au=
thorization checks - expect org.apache.catalina.security.SecurityUtil to ta=
ke this over.=0A>Curiously, by the time it comes to org.apache.catalina.sec=
urity.SecurityUtil.execute(...) applying Subject.doAsPrivileged, it is done=
 with another javax.security.auth.Subject instance.=0A>=0A>Having looked a =
bit into it what is happening, I see the followings=0A>- org.apache.catalin=
a.security.SecurityUtil.execute(...) looks for a subject to be present in t=
he session object with key Globals.SUBJECT_ATTR ("javax.security.auth.subje=
ct").=0A>- if it is not present, it will create a new blank Subject contain=
ing only one Principal, which is extracted from the request&#39;s org.apach=
e.catalina.connector.Request object (and store it in the session afterwards=
 under Globals.SUBJECT_ATTR)=0A>- org.apache.catalina.connector.Request&#39=
;s setUserPrincipal(Principal principal) sets the session object with key G=
lobals.SUBJECT_ATTR to a newly initialized javax.security.auth.Subject with=
 a single Principal. =0A>=0A>Summary: to me it seems that the mechanism cur=
rently used to propagate the Subject to org.apache.catalina.security.Securi=
tyUtil.execute(...) _always_ creates a new empty Subject and adds a single =
user principal into it.=0A>=0A>Questions:=0A>- do I miss something about Su=
bject propagation?=0A>If not:=0A>- is this intentionally planned like this?=
=0A>- would it not make sense to allow Subjects to be propagated to Securit=
yUtil 1:1 from JAAS Login modules to be used as the Subject for privileged =
execution?=0A>=0A>Btw, I am on 7.0.68, but seems that the relevant pieces o=
f code has not been changed by 7.0.75 - most recent version checked. =0A>=
=0A>Thank you for any help upfront!=0A>=0A>Regards,=0A>Gabor=0A> =0A> =0A>=
=0A>---------------------------------------------------------------------=
=0A>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org=0A>For addi=
tional commands, e-mail: users-help@tomcat.apache.org=0A>=0A>=0A

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