Hi all,
these days I prepared a patch to add support for Windows ActiveDirectory as an LDAP option for the GeoServer LDAP Authentication provider.
Before preparing a pull request I would like to collect opinions on the way I implemented it.
Basically I was trying to solve http://jira.codehaus.org/browse/GEOS-5054, which affects ActiveDirectory usage, and in the meantime adding some features helping AD integration.
Tests are still missing but I’m going to add them before making a pull request.
My approach was:
redefine the Spring DefaultLdapAuthoritiesPopulator (BindingLdapAuthoritiesPopulator) if a new flag (bindBeforeGroupSearch) is checked to do searches on the LDAP server in a bound context (the default one doesn’t); unfortunately I was not able to extend the original class since the method to be redefined is declared final
extend the Spring BindingAuthenticator to allow an alternative authentication and user data extraction method ; the default one binds using the dn of the user and extracts data from a simple lookup to that dn, the alternative one binds using the username directly and extracts user data using a filter (the filter is specified by the user instead of userDnPattern and triggers the alternative auth method)
the filter allows to extract data filtering by the userPrincipalName attribute, that is the login username in Microsoft world, this attribute is not part of the dn of the user
an optional userFormat can be used to transform the username given by the user to the effective username to be used for login (for example to add the ActiveDirectory domain extension automatically)
an optional adminGroup can be specified to map a specific ActiveDirectory group to GeoServer ADMIN role (the default ADMINISTRATOR role is usually the admin user name in the Windows world, so it’s not available as a group name)
I think some of these new options can be useful for other kind of LDAP servers too.
I did tests with a Windows 2012 Server. I hope the same can work well on previous versions too. If someone is willing to do a quick test with 2008 or 2003 it will be very appreciated.
This is an example of configuration for the modified provider:
Sorry for the late reply on this. The approach sounds good to me. A couple of thoughts and suggestions.
Perhaps it makes sense to have a separate “ActiveDirectory” provider, rather than overload the default ldap one with more options. Just a suggestion, not sure how much of the existing provider is used in this scheme.
Regardless of one or more providers, it would be good if we could update the docs along with this patch. The relevant page being:
Hi all,
these days I prepared a patch to add support for Windows ActiveDirectory as an LDAP option for the GeoServer LDAP Authentication provider.
Before preparing a pull request I would like to collect opinions on the way I implemented it.
Basically I was trying to solve http://jira.codehaus.org/browse/GEOS-5054, which affects ActiveDirectory usage, and in the meantime adding some features helping AD integration.
Tests are still missing but I’m going to add them before making a pull request.
My approach was:
redefine the Spring DefaultLdapAuthoritiesPopulator (BindingLdapAuthoritiesPopulator) if a new flag (bindBeforeGroupSearch) is checked to do searches on the LDAP server in a bound context (the default one doesn’t); unfortunately I was not able to extend the original class since the method to be redefined is declared final
extend the Spring BindingAuthenticator to allow an alternative authentication and user data extraction method ; the default one binds using the dn of the user and extracts data from a simple lookup to that dn, the alternative one binds using the username directly and extracts user data using a filter (the filter is specified by the user instead of userDnPattern and triggers the alternative auth method)
the filter allows to extract data filtering by the userPrincipalName attribute, that is the login username in Microsoft world, this attribute is not part of the dn of the user
an optional userFormat can be used to transform the username given by the user to the effective username to be used for login (for example to add the ActiveDirectory domain extension automatically)
an optional adminGroup can be specified to map a specific ActiveDirectory group to GeoServer ADMIN role (the default ADMINISTRATOR role is usually the admin user name in the Windows world, so it’s not available as a group name)
I think some of these new options can be useful for other kind of LDAP servers too.
I did tests with a Windows 2012 Server. I hope the same can work well on previous versions too. If someone is willing to do a quick test with 2008 or 2003 it will be very appreciated.
This is an example of configuration for the modified provider:
Try New Relic Now & We’ll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
Sorry for the late reply on this. The approach sounds good to me. A couple
of thoughts and suggestions.
Perhaps it makes sense to have a separate "ActiveDirectory" provider,
rather than overload the default ldap one with more options. Just a
suggestion, not sure how much of the existing provider is used in this
scheme.
I thought about that, but I think the new options (particularly the ones
dealing with roles extracting in a bounded context) could be useful for
other kind of LDAP servers too, not only for ActiveDirectory ones.
Regardless of one or more providers, it would be good if we could update
the docs along with this patch. The relevant page being:
Sorry for the late reply on this. The approach sounds good to me. A couple
of thoughts and suggestions.
Perhaps it makes sense to have a separate "ActiveDirectory" provider,
rather than overload the default ldap one with more options. Just a
suggestion, not sure how much of the existing provider is used in this
scheme.
Regardless of one or more providers, it would be good if we could update
the docs along with this patch. The relevant page being:
I added some tests: tests were missing completely in the security ldap
module, so I needed to add a dependency to spring-ldap-test (with scope
test) to have a mock ldap server.
For the moment I added tests only for the new features added with this
request.
I also updated the docs a little bit to explain the new options and
illustrate how to connect to an ActiveDirectory server.
Sorry for the late reply on this. The approach sounds good to me. A
couple of thoughts and suggestions.
Perhaps it makes sense to have a separate "ActiveDirectory" provider,
rather than overload the default ldap one with more options. Just a
suggestion, not sure how much of the existing provider is used in this
scheme.
Regardless of one or more providers, it would be good if we could update
the docs along with this patch. The relevant page being:
Nice work! I just looked over the pull request and it looks good to me.
Nice improvements.
I added some tests: tests were missing completely in the security ldap
module, so I needed to add a dependency to spring-ldap-test (with scope
test) to have a mock ldap server.
For the moment I added tests only for the new features added with this
request.
I also updated the docs a little bit to explain the new options and
illustrate how to connect to an ActiveDirectory server.
Awesome. Indeed i never got around to figuring out how to setup spring for
testing with ads. Thanks for doing that.
I didn't read in documentation what to insert in the "User lookup pattern",
so I left it blank, but if I test connection I get "No user dn pattern
specified".
Other question: what are the options "Group to use as ADMIN" and "Group to
use as GROUP_ADMIN"?
Thanks for great job, bye.
I didn't read in documentation what to insert in the "User lookup pattern",
so I left it blank, but if I test connection I get "No user dn pattern
specified".
Yes, it's a known bug of the current implementation: the "Test connection"
feature doesn't seem to work with ActiveDirectory. I will open a Jira
ticket about that. This should not prevent the real authentication to work.
Let me know if you can successfully authenticate users or if you have any
issue.
Other question: what are the options "Group to use as ADMIN" and "Group to
use as GROUP_ADMIN"?
They are the ActiveDirectory groups you want to bind to GeoServer system
roles ROLE_ADMINISTRATOR and ROLE_GROUP_ADMIN, so that users belonging to
those groups are automatically assigned administrative privileges.
Yes, it's a known bug of the current implementation: the "Test connection"
feature doesn't seem to work with ActiveDirectory. I will open a Jira
ticket about that. This should not prevent the real authentication to
work.
Let me know if you can successfully authenticate users or if you have any
issue.
Mauro, you are right, the real authentication works.
Thank you very much for quick help.