qpid-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From conflue...@apache.org
Subject [CONF] Apache Qpid > Java Pluggable Authentication Managers
Date Mon, 16 May 2011 08:13:00 GMT
    <base href="https://cwiki.apache.org/confluence">
            <link rel="stylesheet" href="/confluence/s/2042/9/21/_/styles/combined.css?spaceKey=qpid&amp;forWysiwyg=true"
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
    <h2><a href="https://cwiki.apache.org/confluence/display/qpid/Java+Pluggable+Authentication+Managers">Java
Pluggable Authentication Managers</a></h2>
    <h4>Page  <b>added</b> by             <a href="https://cwiki.apache.org/confluence/display/~k-wall">keith
    <div class="notificationGreySide">
         <h4><a name="JavaPluggableAuthenticationManagers-PluggableAuthenticationManagers"></a>Pluggable
Authentication Managers</h4>

<p>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.</p>

<p>Why do we need a pluggable Authentication Manager?</p>

<p>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.</p>

<p>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.</p>

<p>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 .</p>

<h5><a name="JavaPluggableAuthenticationManagers-Proposal%3A"></a>Proposal:</h5>

<p>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.</p>

<h5><a name="JavaPluggableAuthenticationManagers-Keychanges%3A"></a>Key

<p>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
2) AuthenticationManager implementations retain the responsibility for registering the SASL
mechanism(s) with JCA.<br/>
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.<br/>
4) It will be mandatory for an implementation of an AuthenticationManager to be declared in
5) PrincipalDatabaseAuthenticationManager will become a pluggable implementation.  This implementation
will continue to authenticate against a PrincipalDatabase - thus maintaining our current offering.<br/>
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.</p>

<h5><a name="JavaPluggableAuthenticationManagers-ConfigIllustration%3A"></a>Config

<p>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:</p>

<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
                              &lt;class&gt; org.apache.qpid.server.security.auth.manager.database.PlainPasswordFilePrincipalDatabase&lt;/class&gt;
<p>and here’s an imagined configuration of an AuthenticationManager that authenticates
against a Directory.   The configuration items are for illustration purposes only.</p>

<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
               &lt;ldap-server&gt;ldaps:<span class="code-comment">//myldap.apache.org&lt;/ldap-server&gt;
</span>               &lt;port&gt;389&lt;/port&gt;
               &lt;usessl&gt;<span class="code-keyword">true</span>&lt;/usessl&gt;
               &lt;!-- group(s) from the Directory made available to SecurityPlugins via
the JAAS subject --&gt;

<h5><a name="JavaPluggableAuthenticationManagers-ClassDiagram%3A"></a>Class

<p><span class="error">Unable to render embedded object: File (PluggableAuth.png)
not found.</span></p>
    <div id="commentsSection" class="wiki-content pageSection">
       <div style="float: right;">
            <a href="https://cwiki.apache.org/confluence/users/viewnotifications.action"
class="grey">Change Notification Preferences</a>
       <a href="https://cwiki.apache.org/confluence/display/qpid/Java+Pluggable+Authentication+Managers">View
       <a href="https://cwiki.apache.org/confluence/display/qpid/Java+Pluggable+Authentication+Managers?showComments=true&amp;showCommentArea=true#addcomment">Add

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

View raw message