Tomcat 4.1.x JAASRealm Implementation

[James Krygowski <ja...@shaws.com>]

Hey All (Craig particularly)-

Going through the code that exists in 4.1.8, I noticed that in the JAASRealm
comments, Craig makes mention of using classes implementing the Principal
interface to represent Users and Roles.  This sounds like a good approach
given the vagueness surrounding the JAAS implementation once you get into
implementing it.  In the JAASRealm class, there are setters for configuring
the JAASRealm with the names of Principal classes that contain Users and
Roles.  After running a "Find Usages" with IDEA, I wasn't able to find any
code which references these methods.  So, how does the JAASRealm find out
what classes contain users vs. roles?  Is there some kind of magic going on
with the realm config node in server.xml?  I'd like to start using JAAS on
Tomcat since we currently use JAAS for our JRun servers and converting the
existing LoginModules won't be too much of a pain.

jk


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Tomcat 4.1.x JAASRealm Implementation

["Craig R. McClanahan" <cr...@apache.org>]

On Fri, 9 Aug 2002, James Krygowski wrote:

> Date: Fri, 9 Aug 2002 14:39:57 -0400
> From: James Krygowski <ja...@shaws.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> Subject: Tomcat 4.1.x JAASRealm Implementation
>
> Hey All (Craig particularly)-
>
> Going through the code that exists in 4.1.8, I noticed that in the JAASRealm
> comments, Craig makes mention of using classes implementing the Principal
> interface to represent Users and Roles.  This sounds like a good approach
> given the vagueness surrounding the JAAS implementation once you get into
> implementing it.  In the JAASRealm class, there are setters for configuring
> the JAASRealm with the names of Principal classes that contain Users and
> Roles.  After running a "Find Usages" with IDEA, I wasn't able to find any
> code which references these methods.  So, how does the JAASRealm find out
> what classes contain users vs. roles?  Is there some kind of magic going on
> with the realm config node in server.xml?  I'd like to start using JAAS on
> Tomcat since we currently use JAAS for our JRun servers and converting the
> existing LoginModules won't be too much of a pain.
>

As you've undoubtedly discovered, the JAAS spec doesn't provide any
guidance for figuring out which Principal is which in the Subject that
gets returned.  Looking inside some of the existing implementations (such
as the one that can access an NT domain), this was being done by hard
coded instanceof checks on particular Principal subclasses.

So, to generalize this a little, JAASRealm lets you declare the fully
qualified class names of classes that represent your roles (in the
"roleClasses" property).  You can see it used in the createPrincipal()
method inside JAASRealm, where it is checking the classname of each
returned Principal against the list of class names you provided.  When it
finds a match, it assumes that principal.getName() on that Principal will
return the role name that has been authorized for this user.

The "userClasses" property serves a similar purpose for saying which
classes actually represent the user.

NOTE:  The implementation classes themselves need to be visible to
Catalina's internal class loaders for all of this to work.  The simplest
thing to do is put them in a JAR file in $CATALINA_HOME/server/lib, or as
unpacked classes under $CATALINA_HOME/server/classes.

NOTE:  You won't see any direct references to the setRoleClasses() or
setUserClasses() methods.  The code that parses server.xml (the Digester
module) has magic code (well, it's actually separately available in
commons-beanutils :-) in it that matches up attributes in the XML
elements to the corresponding property setters in the class.  So, you
configure one of these beasts like this:

  <Realm className="org.apache.catalina.realm.JAASRealm"
       roleClasses="com.foo.MyFirstRole,com.bar.MySecondRole"
              ... />

and the setter gets called for you via Java's introspection and
reflection capabilities.

> jk
>

Craig


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>