Proposal: Java Broker: Pluggable Authentication Managers

[Keith Wall <ke...@gmail.com>]

I propose to change the Java Broker to allow users to plug-in  
alternative Authentication Manager implementations.  The primary  
driver for this change is to allow authentication decisions to be  
delegated to another system, for instance, an Enterprise Directory.

Why do we need a pluggable Authentication Manager?

It is true we already have pluggable Principal Databases.   Why does  
this not suffice?   I would argue that the abstraction offered by  
PrincipalDatabase does not map well to a large organization.   In a  
large organization functions such as creation/deletion of users and  
changing passwords are delegated to other systems.  These functions  
are not core to Qpid’s use-case, and the offering of such functions  
can raise security concerns and can be a barrier to the adoption of  
Qpid.

To fulfill it's messaging use-cases, Qpid needs only to be able to  
authenticate users and authorise their actions.  We already have a  
fully pluggable authorisation system (SecurityPlugin), but we lack the  
ability to cleanly plug-in authentication.

I am not suggesting that we remove the functionality offered by the  
PrincipalDatabase implementations (Plain/MD5 password databases backed  
by flat file).  I can see these are useful for many users.   The  
proposal retains these implementations although the configuration will  
change .

Proposal:

Currently Qpid makes Authentication decisions in two places: Qpid  
client authentication decisions (via SASL) are made in  
AuthenticationManager.authenticate(), and operator (JMX interaction)  
authentication decisions are made separately in  
RMIPasswordAuthenticator.    To be able to cleanly abstract  
authentication, these functions must be exposed by a single façade.  I  
propose to make AuthenticationManager that façade.

Key changes:

1) AuthenticationManager implementations take responsibility for all  
authentication decisions. In other words, they retain the  
responsibility for SASL authentication decisions and acquire the  
responsibility for non-SASL authentication decisions where the caller  
provides userid/password.
2) AuthenticationManager implementations retain the responsibility for  
registering the SASL mechanism(s) with JCA.
3) Implementations of the authenticate() method take responsibility  
for populating a JAAS Subject. This will allow the authentication  
manager to expose the user's identity (UsernamePrincipal) and group  
memberships (GroupPrincipal) to remainder of the application.   The  
group information could be used by a SecurityPlugin to make access  
decisions based on group information from a Directory.
4) It will be mandatory for an implementation of an  
AuthenticationManager to be declared in config.xml.
5) PrincipalDatabaseAuthenticationManager will become a pluggable  
implementation.  This implementation will continue to authenticate  
against a PrincipalDatabase - thus maintaining our current offering.
6) Other AuthenticationManager implementations would allow  
authentication decisions to be made in other ways, for instance, we  
might have a LDAPAuthentionationManager to delegate authentication  
decisions to an Enterprise Directory.

Config Illustration:

To illustrate, here is a config.xml snippet for a Qpid instance  
secured by a etc/password file.  This illustrates how the current  
functionality would be maintained:

<security>
<authentication-manager>
                 
<class> 
org.apache.qpid.server.security.auth.manager.PrincipalDatabaseAuthenticationManager< 
/class>
                <principal-database>
                               <class>  
org.apache.qpid.server.security.auth.manager.database.PlainPasswordFilePrincipalDatabase< 
/class>
                               <attributes>
                                               
<attribute><name>passwordFile</name><value>etc/password</value></ 
attribute>
                               </attributes>
                </principle-database>
</authentication-manager>
…
</security>

and here’s an imagined configuration of an AuthenticationManager that  
authenticates against a Directory.   The configuration items are for  
illustration purposes only.

<security>
<authentication-manager>
                 
<class> 
org.apache.qpid.server.security.auth.manager.LdapAuthenticationManager< 
/class>
                <ldap-server>ldaps://myldap.apache.org</ldap-server>
                <port>389</port>
                <usessl>true</usessl>
                <user-dn-query>uid={0},ou=staff,dc=example,dc=com</ 
user-dn-query>
                <!-- group(s) from the Directory made available to  
SecurityPlugins via the JAAS subject -->
                <group-query>(&(objectCategory=group)(member=uid= 
{0},ou=staff,dc=example,dc=com))</group-query>
</authentication-manager>
…
</security>

I have annotated class diagrams to further illustrate the proposal.   
These can be found here:

https://cwiki.apache.org/confluence/display/qpid/Java+Pluggable+Authentication+Managers

Any thoughts?   Please comment on this thread, rather than commenting  
on the Wiki page.
>

Re: Proposal: Java Broker: Pluggable Authentication Managers

[Andrew Kennedy <an...@gmail.com>]

On 16 May 2011, at 09:16, Keith Wall wrote:
> I propose to change the Java Broker to allow users to plug-in alternative Authentication Manager implementations.  The primary driver for this change is to allow authentication decisions to be delegated to another system, for instance, an Enterprise Directory.

+1, Good stuff. Thanks, Keith.

This is *exactly* what we need for Qpid to be taken seriously in the Enterprise Messaging and Middleware space! I'll have a proper look at the proposal and give you any ideas or feedback I have later, but this looks very promising.

Cheers,
Andrew.
--
-- andrew d kennedy ? apache qpid project : http://qpid.apache.org/ ;


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org