Re: another problem with JAAS

[Adam Hardy]

Michiel,
that would be the one that you put there, right?
Adam

On 04/23/2004 10:33 AM Michiel Toneman wrote:
Oops, missed the "How" ;-)

       Subject subject = 
(Subject)session.getAttribute("javax.security.auth.subject");

       if (subject == null) {
           subject = new Subject();
       } else {
           System.out.println("According to the Filter, the subject is: 
" + subject);
       }

and once we have logged in our subject:

       session.setAttribute("javax.security.auth.subject", subject);

I'll write this up over the weekend....

Cheers,

Michiel

Alan Weissman wrote:

Yes but how? :)

What is the key that you use in the session?

-----Original Message-----
From: Michiel Toneman [mailto:[EMAIL PROTECTED] Sent: 
Thursday, April 22, 2004 12:51 PM
To: Tomcat Users List
Subject: Re: another problem with JAAS

Hi Alan,

That's correct, I overwrite the subject.

Michiel

Alan Weissman wrote:

 

Hey Michiel -

How did you overwrite Tomcat's Subject in the Session with your own?

Thanks,
Alan
-----Original Message-----
From: Michiel Toneman [mailto:[EMAIL PROTECTED] Sent: 
Thursday, April 22, 2004 9:51 AM
To: Tomcat Users List
Subject: Re: another problem with JAAS

Hi Beloglazov,

I was running into the same problem. As far as I can tell (anyone on
  
the
 

list, please correct me if I'm wrong), Tomcat primarily uses JAAS for 
authentication, but it is pretty useless for  authorisation. I have 
no idea why the JAASRealm goes to all the trouble of setting up a 
Subject etc... when you can't use them in your own policy. All you 
can do is
  
use
 

"isUserInRole()" to check for the *name* of your role Principal. This 
totally defeats the point of using JAAS IMHO.

I am using a JAAS implementation with is custom Policy that assigns 
Permission(s) based on various types of Principal that I assign to 
the Subject. My webapps can then do proper java Permission checks 
(AccessController.checkPermission(perm)).

The way to go in Tomcat is using a filter, setting up (LoginContext) 
your Subject and use a doAsPrivileged() to wrap the servlet call. 
(see my earlier post on the list). However, this does not work on 
Tomcat (works fine on JRun4) because the filter and servlet are 
evaluated by Tomcat in different security contexts. The solution was 
to overwrite Tomcat's Subject in the session by my own Subject.

I'm writing a tutorial on this, but it isn't ready yet. If you need 
an implementation fast, and the above is not enough to go on, I can 
speed up the writing ;-)

Cheers,

Michiel

Beloglazov Maksim wrote:



  

Hello,

I've written a JAAS LoginModule and my web application successfully 
authorizes with it. But! While the authorization is successful, Tomcat
 
    


  

does not recognize user Principals and roles which I assign in login 
module and returns that I have logged as a *null* user with no roles 
assigned to it.

server.xml:
....
<Realm className="org.apache.catalina.realm.JAASRealm"
        appName="merx"
        userClassNames="ru.mb.security.jaas.RdbmsPrincipal"
        roleClassNames="ru.mb.security.jaas.RdbmsRole"
        debug="99"/>
....
ru.mb.security.jaas.RdbmsPrincipal and ru.mb.security.jaas.RdbmsRole 
are implementations of java.security.Principal interface. How can I 
force Tomcat recognize these Principals in a proper way? Can be the 
problem with moving javax.security.Principal of earlier JDKs to 
java.security.Principal in modern ones?

Any help is greatly appreciated.

Beloglazov Maksim.

 
    


  


 





--
struts 1.2 + tomcat 5.0.19 + java 1.4.2
Linux 2.4.20 Debian
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]