tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Biernat <>
Subject Addition of roles in CoyotePrincipal similiar to GenericPrincipal
Date Thu, 30 Oct 2003 02:30:03 GMT

I'm not sure wether this has been discussed before, but I'm wondering wether
theres any reason why the CoyotePrincipal class couldnt be extended to
maintain a list of roles, similiar to what is now done with the
GenericPrincipal in the catalina realm package.

I have a scenario at the moment where I'm using tomcat with IIS/Apache
sitting in front of it so that I can take advantage of integrated windows
authentication (For Apache I use mod_auth_sspi). This works fine for simple
apps that only have a default application role. 

In the case where I need to use role based security with the roles being
equal to nt domain groups,  I was lucky in that ActiveDirectory is used to
authenticate the network logons with meant all I had todo was extend the
existing JNDIRealm and override the hasRole method so it read the role
information from ActiveDirectory. My realm is only used for role info only,
not authentication (As the web server has already done that) so in
overridden hasRole method, the passed in Principal is of type
CoyotePrincipal. I can read my role information fine but the issue I'm
having is that since the CoyotePrincipal cannot hold roles, I have two

1. Everytime the hasRole method is invoked by the container, reread the
roles from Active Directory.
2. Using the SessionManager which is available via the Realms manager,
iterate through each active session and find the one this principal is for.
The principal is not associated with a session (only a request), so how can
i determine the current session for the current principal? One way I have
gotten around this is to create a custom valve implementation which
intercepts the request, and takes the username from the request and places
into a session attribute so i can match sessions and principals but this is
a hack.

If the CoyotePrincipal has a way to hold onto role information like the
other principals then this would solve the problems I currently have. 

If anyone has some other ideas please let me know.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message