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 invalidated                HttpSession 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 Subject                if (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 reference                if (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 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to