You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by huntc <hu...@mac.com> on 2009/03/12 07:56:52 UTC
SSL authorisation using a client's subject DN for JNDI
Hi there,
I have a situation where I need to support authentication and authorisation
for endpoints connecting to my broker. I have successfully configured an
LDAP server for this purpose and have everything working.
My concern though is that endpoints must provide a username and password to
establish their identity. Indeed ActiveMQ also needs to provide its username
and password so that it can interrogate the LDAP store.
This then requires that passwords are stored in the clear somewhere;
generally in some configuration file like activemq.xml. I realise that I can
use operating system permissions to lock the configuration files down, but I
am looking for a better way.
I am presently thinking of writing my own JAAS LoginModule to authorise
endpoints that have successfully authenticated using mutual SSL
authentication i.e. verifies the client's certificate. On login my module
would extract the subject DN from the client's certificate by getting the
public certificate from the Subject object. It would then perform an JNDI
search for the groups that has the DN as a member. The CNs of member groups
would then be established as roles (much like the existing
org.apache.activemq.jaas.LDAPLoginModule does).
To further aid security I would disallow all but SSL based communication
with the broker.
Does the strategy make sense? Is there a better way of avoiding storing
usernames and passwords in the clear?
Thank you for your time.
Kind regards,
Christopher
--
View this message in context: http://www.nabble.com/SSL-authorisation-using-a-client%27s-subject-DN-for-JNDI-tp22470806p22470806.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: SSL authorisation using a client's subject DN for JNDI
Posted by Dejan Bosanac <de...@nighttale.net>.
Hi Christopher,
I added your post to the list of articles
http://cwiki.apache.org/confluence/display/ACTIVEMQ/Articles
I'll try to incorporate your work into amq when time permits.
Thanks
--
Dejan Bosanac
Open Source Integration - http://fusesource.com/
ActiveMQ in Action - http://www.manning.com/snyder/
Blog - http://www.nighttale.net
On Tue, Mar 17, 2009 at 1:50 PM, huntc <hu...@mac.com> wrote:
>
> The promised blog entry:
>
>
> http://christopherhunt-software.blogspot.com/2009/03/mutual-ssl-authentication-and-ldap.html
> --
> View this message in context:
> http://www.nabble.com/SSL-authorisation-using-a-client%27s-subject-DN-for-JNDI-tp22470806p22558453.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>
Re: SSL authorisation using a client's subject DN for JNDI
Posted by huntc <hu...@mac.com>.
The promised blog entry:
http://christopherhunt-software.blogspot.com/2009/03/mutual-ssl-authentication-and-ldap.html
--
View this message in context: http://www.nabble.com/SSL-authorisation-using-a-client%27s-subject-DN-for-JNDI-tp22470806p22558453.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: SSL authorisation using a client's subject DN for JNDI
Posted by huntc <hu...@mac.com>.
I have now written a login module that extends AMQ's CertificateLoginModule
(which I found along the way!). The login module fulfills my goal of using a
directory service to authorise an authenticated SSL client.
The project is under the Apache 2.0 licence and its project page and
download can be found at:
http://code.google.com/p/jaasloginmodules/
Securing AMQ appears to be poorly documented which is unfortunate because it
can be done very nicely. I will write a blog entry describing what I have
ended up doing very shortly. I shall post the link to the blog here.
--
View this message in context: http://www.nabble.com/SSL-authorisation-using-a-client%27s-subject-DN-for-JNDI-tp22470806p22553464.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: SSL authorisation using a client's subject DN for JNDI
Posted by huntc <hu...@mac.com>.
djencks wrote:
>
>
> This looks to me like it will work but I don't understand why it would
> be more secure than having an activemq ldap user password on disk
> somewhere.
>
I think that there is key difference between attempting to lock down ldap
access and permitting anonymous access to a branch of the ldap store. With
the latter one is recognising that there is a branch of the ldap store that
contains non-sensitive information.
So then the question becomes: is it going to be a security issue knowing
which subject DNs belong to the activemq groups?
Looking at it another way: is having public access to activemq group member
information any more insecure than browsing your /etc/group file for a list
of unix user members? :-)
Thanks again for the dialogue.
Kind regards,
Christopher
--
View this message in context: http://www.nabble.com/SSL-authorisation-using-a-client%27s-subject-DN-for-JNDI-tp22470806p22486792.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: SSL authorisation using a client's subject DN for JNDI
Posted by huntc <hu...@mac.com>.
djencks wrote:
>
>
> This looks to me like it will work but I don't understand why it would
> be more secure than having an activemq ldap user password on disk
> somewhere.
>
>
I thought that I should just mention that the login module I developed
(http://code.google.com/p/jaasloginmodules/) permits both ActiveMQ
authenticating with directories and anonymous access.
--
View this message in context: http://www.nabble.com/SSL-authorisation-using-a-client%27s-subject-DN-for-JNDI-tp22470806p22556554.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: SSL authorisation using a client's subject DN for JNDI
Posted by David Jencks <da...@yahoo.com>.
On Mar 12, 2009, at 5:49 AM, huntc wrote:
>
>
> huntc wrote:
>>
>> You're right in that activemq still has to bind itself to perform a
>> search
>> to see which groups an endpoint's dn belongs to. I did forget about
>> that.
>>
>>
> Perhaps this bind could be achieved using a mechanism such as SASL/
> GSSAPI?
>>
>
> After lots of reading, and experimenting, perhaps the way for AMQ to
> determine the roles is via anonymous LDAP access.
>
> What I've done is specified a hierarchy like:
>
>
> ou=system
> ou=groups
> ou=activemq
> cn=activemq-users
> cn=com.classactionpl.javaFlightTopic.subscribers
> cn=jms-services
>
>
> I've then enabled anonymous access and enabled access control. By
> default
> (at least with ApacheDS) no one can do a thing; you have to explicitly
> enable who can see what. What I have done is allowed anonymous
> access to
> browse and read everything below "ou=activemq,ou=groups,ou=system"
> only. I
> have used an ACI under "ou=activemq,ou=groups,ou=system":
>
>
> {
> identificationTag "allUsersBrowseACISubentry",
> precedence 0,
> authenticationLevel none,
> itemOrUserFirst userFirst:
> {
> userClasses { allUsers },
> userPermissions
> {
> {
> precedence 0,
> protectedItems { allUserAttributeTypes, entry },
> grantsAndDenials { grantBrowse, grantRead }
> }
> }
> }
> }
>
>
> Now AMQ can potentially connect anonymously and determine the groups
> that a
> uid belongs to. The following ldapsearch command demonstrates how to
> search
> for the groups user "camel" belongs to:
>
>
> ldapsearch -x -H ldap://localhost:10389 -s one -b
> "ou=activemq,ou=groups,ou=system"
> "(member=uid=camel,ou=users,ou=system)" cn
> member
>
>
> My login plugin can therefore rely upon SSL for authentication. Upon
> successful authentication the subject DN of the client's certificate
> can be
> anonymously looked up via LDAP to determine the roles (groups) for
> authorisation.
>
> Am I barking mad or does this appear to be a secure solution?
> Remember that
> nothing but mutual SSL authentication with AMQ will be permitted.
I'm actually not an ldap expert :-)
This looks to me like it will work but I don't understand why it would
be more secure than having an activemq ldap user password on disk
somewhere.
IIUC you have:
roles exposed to anyone who can get to your ldap
secret activemq cert on disk
secret cert for each client on disk
I think this would be more secure:
create activemq user who can only read the roles info from ldap and
disable anonymous access
put that user/pw info on disk accessible to activemq server
use ssl certs as now for client auth
Once you've done this however it looks like there is the same number
of places you'd have secure info on disk as with the plain user/pw +
ldap solution, although the info would be certs rather than passwords.
thanks
david jencks
>
>
> Kind regards,
> Christopher
> --
> View this message in context: http://www.nabble.com/SSL-authorisation-using-a-client%27s-subject-DN-for-JNDI-tp22470806p22475654.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: SSL authorisation using a client's subject DN for JNDI
Posted by huntc <hu...@mac.com>.
huntc wrote:
>
> You're right in that activemq still has to bind itself to perform a search
> to see which groups an endpoint's dn belongs to. I did forget about that.
>
>
Perhaps this bind could be achieved using a mechanism such as SASL/GSSAPI?
>
After lots of reading, and experimenting, perhaps the way for AMQ to
determine the roles is via anonymous LDAP access.
What I've done is specified a hierarchy like:
ou=system
ou=groups
ou=activemq
cn=activemq-users
cn=com.classactionpl.javaFlightTopic.subscribers
cn=jms-services
I've then enabled anonymous access and enabled access control. By default
(at least with ApacheDS) no one can do a thing; you have to explicitly
enable who can see what. What I have done is allowed anonymous access to
browse and read everything below "ou=activemq,ou=groups,ou=system" only. I
have used an ACI under "ou=activemq,ou=groups,ou=system":
{
identificationTag "allUsersBrowseACISubentry",
precedence 0,
authenticationLevel none,
itemOrUserFirst userFirst:
{
userClasses { allUsers },
userPermissions
{
{
precedence 0,
protectedItems { allUserAttributeTypes, entry },
grantsAndDenials { grantBrowse, grantRead }
}
}
}
}
Now AMQ can potentially connect anonymously and determine the groups that a
uid belongs to. The following ldapsearch command demonstrates how to search
for the groups user "camel" belongs to:
ldapsearch -x -H ldap://localhost:10389 -s one -b
"ou=activemq,ou=groups,ou=system" "(member=uid=camel,ou=users,ou=system)" cn
member
My login plugin can therefore rely upon SSL for authentication. Upon
successful authentication the subject DN of the client's certificate can be
anonymously looked up via LDAP to determine the roles (groups) for
authorisation.
Am I barking mad or does this appear to be a secure solution? Remember that
nothing but mutual SSL authentication with AMQ will be permitted.
Kind regards,
Christopher
--
View this message in context: http://www.nabble.com/SSL-authorisation-using-a-client%27s-subject-DN-for-JNDI-tp22470806p22475654.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: SSL authorisation using a client's subject DN for JNDI
Posted by huntc <hu...@mac.com>.
Hi David,
My responses:
djencks wrote:
>
> ??? I'm not familiar with the activemq stuff but the ldap login
> modules I've seen work by binding to ldap using the client's supplied
> user name and password. If it works, then the user name/password is
> valid and you can go on to look for groups/roles/whatever, otherwise
> the username/password is not valid. So, activemq does not need a
> "system identity" known to ldap for this to work.
>
This does not appear to be so with the
org.apache.activemq.jaas.LDAPLoginModule. What happens is the following
happy path according to Wireshark:
1. bind as activemq user
2. search for endpoint user
3. bind as endpoint user
4. get the base object for the endpoint user (not sure why...)
5. bind as activemq user
6. search for groups that the endpoint user belongs to
djencks wrote:
>
> In ldap I think the usual strategy is to hash the stored passwords and
> also hash the incoming supplied passwords. Thus, no passwords in the
> clear.
>
Yes indeed - over the wire - my issue is with passwords being stored on
disk.
djencks wrote:
>
> With this strategy I think you need to authenticate activemq to the
> ldap system?? or can you use the client cert to authenticate the
> original client? In either case it doesn't really seem different to
> me than the username/password case except your description appears to
> require an identity known to ldap for activemq. Unless you require
> the admin to type in the credentials when starting activemq, I don't
> see how you're going to avoid storing the credentials in the clear on
> disk.
>
You're right in that activemq still has to bind itself to perform a search
to see which groups an endpoint's dn belongs to. I did forget about that.
Perhaps this bind could be achieved using a mechanism such as SASL/GSSAPI?
djencks wrote:
>
> Maybe I'm misunderstanding what you are proposing....
>
I appreciate your response.
Kind regards,
Christopher
--
View this message in context: http://www.nabble.com/SSL-authorisation-using-a-client%27s-subject-DN-for-JNDI-tp22470806p22471481.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: SSL authorisation using a client's subject DN for JNDI
Posted by David Jencks <da...@yahoo.com>.
On Mar 11, 2009, at 11:56 PM, huntc wrote:
>
> Hi there,
>
> I have a situation where I need to support authentication and
> authorisation
> for endpoints connecting to my broker. I have successfully
> configured an
> LDAP server for this purpose and have everything working.
>
> My concern though is that endpoints must provide a username and
> password to
> establish their identity. Indeed ActiveMQ also needs to provide its
> username
> and password so that it can interrogate the LDAP store.
??? I'm not familiar with the activemq stuff but the ldap login
modules I've seen work by binding to ldap using the client's supplied
user name and password. If it works, then the user name/password is
valid and you can go on to look for groups/roles/whatever, otherwise
the username/password is not valid. So, activemq does not need a
"system identity" known to ldap for this to work.
In ldap I think the usual strategy is to hash the stored passwords and
also hash the incoming supplied passwords. Thus, no passwords in the
clear.
>
>
> This then requires that passwords are stored in the clear somewhere;
> generally in some configuration file like activemq.xml. I realise
> that I can
> use operating system permissions to lock the configuration files
> down, but I
> am looking for a better way.
>
> I am presently thinking of writing my own JAAS LoginModule to
> authorise
> endpoints that have successfully authenticated using mutual SSL
> authentication i.e. verifies the client's certificate. On login my
> module
> would extract the subject DN from the client's certificate by
> getting the
> public certificate from the Subject object. It would then perform an
> JNDI
> search for the groups that has the DN as a member. The CNs of member
> groups
> would then be established as roles (much like the existing
> org.apache.activemq.jaas.LDAPLoginModule does).
With this strategy I think you need to authenticate activemq to the
ldap system?? or can you use the client cert to authenticate the
original client? In either case it doesn't really seem different to
me than the username/password case except your description appears to
require an identity known to ldap for activemq. Unless you require
the admin to type in the credentials when starting activemq, I don't
see how you're going to avoid storing the credentials in the clear on
disk.
Maybe I'm misunderstanding what you are proposing....
david jencks
>
>
> To further aid security I would disallow all but SSL based
> communication
> with the broker.
>
> Does the strategy make sense? Is there a better way of avoiding
> storing
> usernames and passwords in the clear?
>
> Thank you for your time.
>
> Kind regards,
> Christopher
> --
> View this message in context: http://www.nabble.com/SSL-authorisation-using-a-client%27s-subject-DN-for-JNDI-tp22470806p22470806.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>