tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <ahardy.str...@cyberspaceroad.com>
Subject Re: JAAS problems migrating from JRun
Date Tue, 06 Apr 2004 16:38:31 GMT
I'm no expert on the internals of tomcat, sorry. You might be looking at 
a hole in the implementation. I haven't used the JAAS authorization 
policy mechanism, I rely solely on roles.

Adam

On 04/06/2004 05:18 PM Michiel Toneman wrote:
> Adam,
> 
> I've been at this all day, and I seem to be banging my head against a 
> really well-constructed wall. I followed your advice by going the 
> security-constraints/Realm route.
> 
> I've build a minimal JAAS implementation which, in combination with  
> JAASRealm, works fine for *authentication*. However, when I want to 
> access the Principals I've assigned in my LoginModule within my 
> CustomPolicy for *authorization*,  I get nothing.
> 
> i.e. in my CustomPolicy:
> 
> --------------------------------
> getPermissions(ProtectionDomain domain) {
>        PermissionCollection pc = deferredPolicy.getPermissions(domain);
>             // get principals associated with domain
>        Principal[] principals = domain.getPrincipals();
> .....
> }
> --------------------------------
> 
> domain.getPrincipals() returns no policies. Ok, so I go to the Subject 
> (using a PrivilegedAction):
> 
>     Subject.getSubject(AccessController.getContext()).getPrincipals();
> 
> and again no Principals. The Subject is empty.
> 
> I've confirmed this by calling a JSP which includes <%= 
> Subject.getSubject(AccessController.getContext()) %>
> 
> this just prints: "Subject:", so it seems that the Subject I've worked 
> so hard to create is "lost".
> 
> How can I get this to work? I need to access the Principals in my 
> CustomPolicy, so that I can assign custom permissions to the 
> PermissionCollection of the domain.
> 
> Thanks,
> 
> Michiel
> 
> P.S. Just to show that the LoginModule / JAASRealm seem to be working:
> 
> catalina_log:
> 2004-04-06 16:51:02 JAASRealm[Catalina]: Returning username bluppie
> 
> catalina.out:
> Assigned principal bluppie of type security.UserPrincipal to user bluppie
> Assigned principal authenticateduser of type security.RolePrincipal to 
> user bluppie
> Assigned principal developer of type security.CustomPrincipal to user 
> bluppie
> 
> 
> 
> Adam Hardy wrote:
> 
>> Michiel,
>> you are programming your own login trigger in a filter - I don't this 
>> this will work (although I'm happy to be wrong).
>>
>> I think tomcat is only going to adopt your principals as authenticated 
>> if you protect whichever pages necessary via security-constraints in 
>> the deployment descriptor.
>>
>> You must set up a LoginModule that tomcat will find, and in this 
>> LoginModule tomcat gives you a call-back-handler which you use to do 
>> the authentication. You must then set your Subject, which is also 
>> passed to you by tomcat.
>>
>> Adam
>>
>> On 04/06/2004 01:39 AM Michiel Toneman wrote:
>>
>>> Hi All,
>>>
>>> The company I work for is attempting to move from JRun 3/4 to Tomcat
>>> 5.0.19. So far it has been smooth sailing, and the migration is going
>>> better than expected.
>>> However, before the migration we were about to deploy a JAAS framework
>>> on JRun 4. This framework doesn't seem to work at all well in Tomcat 5.
>>> I've implemented a tailored JAAS framework with various types of
>>> Principals that grant certain (custom) Permissions in my own Policy. To
>>> enforce this onto the webapp, I used a Filter to establish a
>>> LoginContext and then "wrap" the servlet in a Subject.doAsPrivileged
>>> call. To clarify: I'm not looking for authentication through JAAS (I've
>>> imlemented this in a minimal way), but I'm looking to JAAS for some more
>>> elaborate authorization tricks.
>>>
>>> In my doFilter (simplified):
>>>
>>>   LoginContext lc = new LoginContext("MyJaas", new 
>>> MyHttpAuthCallbackHandler(request));
>>>   lc.login();
>>>   Subject.doAsPrivileged(lc.getSubject(),new 
>>> FilteredAction(request,response,chain) , null);
>>>
>>> where FilteredAction is an inner class:
>>>
>>> -----------------------------------------------------------
>>>         class FilteredAction implements PrivilegedAction {
>>>                         ServletRequest faRequest;
>>>                         ServletResponse faResponse;
>>>                         FilterChain faChain;
>>>                         public FilteredAction(ServletRequest request, 
>>> ServletResponse response, FilterChain chain) {
>>>                                         this.faRequest=request;
>>>                                         this.faResponse=response;
>>>                                         this.faChain=chain;
>>>                         }
>>>                         public Object run() {
>>>                                         try {
>>>                                                         
>>> faChain.doFilter(faRequest, faResponse);
>>>                                         } catch (Exception e) {
>>>                                                         
>>> e.printStackTrace();
>>>                                         }
>>>                                         return null;
>>>                         }
>>>         }
>>> -----------------------------------------------------------
>>>
>>> I replace the default Policy with my own policy that adds permissions
>>> based on principals assigned in the LoginContext. This is done in the
>>> Filter's init:
>>>
>>> -----------------------------------------------------------
>>>         public void init(FilterConfig config) throws ServletException {
>>>                         Policy orgPolicy = Policy.getPolicy();
>>>                                                                             
                                                                                         
                                                                                         
               
>>>                         if (orgPolicy instanceof MyPolicy) {
>>>                                         // we already did this once 
>>> upon a time..
>>>                         } else {
>>>                                         Policy.setPolicy(new 
>>> MyPolicy(orgPolicy));
>>>                         }
>>>         }
>>> -----------------------------------------------------------
>>>
>>> This works like a charm on JRun (it's a "textbook" example on the web).
>>> However, it fails miserably on Tomcat 5. It looks like the Filter is
>>> being evaluated in a different security context by Tomcat than the
>>> Servlet itself (based on evaluation of stacktraces generated in my
>>> custom Policy class). Therefore, none of the Principals assigned to the
>>> Subject in the Filter are available in the Servlet (when
>>> MyPolicy.getPermissions() is called).
>>> Does anyone have an idea how I should go about getting (something like)
>>> this to work on Tomcat?
>>>
>>> Any help would very much appreciated.
>>> Cheers,
>>>
>>> Michiel Toneman
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>>
>>>
>>
>>
> 
> 


-- 
struts 1.2 + tomcat 5.0.19 + java 1.4.2
Linux 2.4.20 Debian


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


Mime
View raw message