tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <ar...@exoffice.com>
Subject Re: authorization providers (was More on JAAS)
Date Tue, 18 Apr 2000 05:01:26 GMT
> 1) First people should be able freely write security interceptors as
> they see fit.

+1

> 3) we should be able to populate the Roles object
> While I can authorize a user per role (e.g. LDAP group), I cannot
> set the Roles value for when someone wants that information from
> request.getRoles().

Out of curiosity how do you map a user into roles?

In our case we have a role entry in a given DN space
(uid=...,ou=Roles,...) which lists the users under that role (by DN). We
pre-load the roles into memory (doesn't take that much space) and we
determine the roles for a user when the user authenticates. To deal with
mass quantity of users we use mapping of roles to directories of users
and default roles.

> The only item I really lacked was the ability to populate the roles
> as I said before. This could be fixed in the Security Interceptor by
> populating a hashtable or map that was updated on each call to
> userInRole and then passed onto the Request object.

JAAS would probably define that as a RoleCredential which you can ask
isInRole(). The RoleCredential is placed in the Subject (the security
context) by the login module, so the login module can place a
fully-loaded object, or a lazy-loading object.


> But what about X.509 or kerberos? I think perhaps we can solve
> that adding 2 more signatures to the checkPassword and
> userInRole.

You would put some credential object (X509Credential, KerberosTicket)
inside Subject before authenticating, and the login modules can grab
that object and use it for authentication if they support it.

Of you could have JAAS callbacks, but I hate those.

arkin

> Instead of taking username and passwords they could take either
> an array of bytes or a generic Object. The SecurityInterceptor
> would only call these versions of the methods if the method of
> authentication/authorization was not BASIC,DIGEST or FORM.
> 
> I'm not exactly sure how to handle multiple interceptors yet.
> 
> The actual implementors of the interceptors could use whatever
> mechanism they wished (JNDI, JAAS, Kerberos, etc) as long as
> they extended the proper class.
> 
> The default provider would simply implement this API. We could
> then provide extras if we wanted that people could optionally
> compile and add in, just like you can with Apache.
> 
> I'm under a tight deadline right now to finish my chapter that started
> all of this. I'll try to get at least my source code published to the
> Web this week (if people want me to submit it to Tomcat, I can, but
> I'd rather wait until this is settled).
> 
> Mark
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Mime
View raw message