Spring Security Plugin

[iowadeifan]

We have installed the spring-security-core into our application and are using the database to hold user and role information.  Just as in basic tutorial - http://blog.springsource.com/2010/08/11/simplified-spring-security-with-grails/

Now we want to switch to using ldap and the spring-security-ldap plugin.  What do we have to change in our application to now use ldap assuming we were setup for the database tables?   Do we have to rip those domain classes out?  I realize you need core plugin to use any of the others, but I can't find any good documentation on how to transition.

Thanks

[Nick Vaidyanathan]

+1. I'm running into the same issue now. The documentation path from basic usage of core to other plugins is really poor.

I expect you're right that the s2-quickstart script's domain classes are unnecessary when using other plugins, but I can't find any definitive confirmation. When I have them and I try to login with an LDAP user, the user cannot be found (even when I have a Person domain class and set
grails.plugins.springsecurity.ldap.mapper.userDetailsClass='person').

When I remove the classes and try to login in Grails 2.0.0.M2, I get :

Error 500: Internal Server Error

URI

/Indication/j_spring_security_check

Class

java.lang.RuntimeException

Message

The specified user domain class 'Person' is not a domain class

Trace

   Line | Method
->> 886 | runTask in java.util.concurrent.ThreadPoolExecutor$Worker
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
|   908 | run     in     ''
^   662 | run . . in java.lang.Thread

Note the abbreviated stack trace makes this rather not useful.

From The section in spring security core plugin on required and optional domain classes, it seems like a person is required unless a custom UserDetailsService is implemented.

When I try to follow the approach listed in the spring-security-ldap documentation section 2, CustomUserDetailsContextMapper, I'm unable to get it to work.

Frustratingly, it looks like a mishmash of additional properties are added by the LDAP plugin, and the settings beyond the initial (for example, when I want to use persistent cookies) are not clear. For example:

ldap.mapper. userDetailsClass

null (create an LdapUserDetailsImpl)

use 'person' to create a Person, 'inetOrgPerson' to create an InetOrgPerson, or null to create an LdapUserDetailsImpl

Does this mean that I have to create a LdapUserDetailsImpl myself (is that even a documented thing? The example shows just a UserDetailsService implementation, not LdapUserDetails)
Where do Person and InetOrgperson come from?

It would be really nice to see a screencast or something following a simple setup example. Most of the resources Google-able seem to use old versions of Spring Security/Acegi, and it's hard to know how to translate that into the current iteration. Even a 5 minute "Given/When/Then" with a dummy LDAP/CAS/etc server screencast would be useful for these auxiliary plugins..

Help?      

On Wed, Aug 24, 2011 at 4:37 PM, iowadeifan <[hidden email]> wrote:

We have installed the spring-security-core into our application and are using
the database to hold user and role information.  Just as in basic tutorial -
http://blog.springsource.com/2010/08/11/simplified-spring-security-with-grails/

Now we want to switch to using ldap and the spring-security-ldap plugin.
What do we have to change in our application to now use ldap assuming we
were setup for the database tables?   Do we have to rip those domain classes
out?  I realize you need core plugin to use any of the others, but I can't
find any good documentation on how to transition.

Thanks

--
View this message in context: http://grails.1312388.n4.nabble.com/Spring-Security-Plugin-tp3766975p3766975.html
Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[mmorett]

Ditto.  The Spring Security Core plugin is easy as cake.  Trying to switch to using it with the LDAP plugin is a mission in patience and googling your ass off.

The first thing you read in "Section 2. Usage" is:

"There isn't much that you need to do in your application to use LDAP. Just install this plugin, and configure any required parameters and whatever optional parameters you want in Config.groovy. "

Ummm...no.   Tried that.  Like you, I keep getting "The specified user domain class 'Person' is not a domain class".

I'm telling it I want to use LDAP.  It keeps looking for a table.

As for using the MyUserDetailsContextMapper mentioned later in the page, it mentions:

"There are three options for mapping LDAP attributes to UserDetails data (as specified by the grails.plugins.springsecurity.ldap.mapper.userDetailsClass config attribute)..."

Except, this attribute isn't even mentioned in the "There isn't much that you need to do in your application to use LDAP" section.  It's probably an optional attribute.  Even so, the code snippet is syntactically incorrect (just try and paste it).

The hunt for an answer to this continues.

Michael.

[ideasculptor]

On Tue, May 22, 2012 at 4:22 PM, mmorett <[hidden email]> wrote:

Ditto.  The Spring Security Core plugin is easy as cake.  Trying to switch to
using it with the LDAP plugin is a mission in patience and googling your ass
off.

The first thing you read in "Section 2. Usage" is:

"There isn't much that you need to do in your application to use LDAP. Just
install this plugin, and configure any required parameters and whatever
optional parameters you want in Config.groovy. "
 

Ummm...no.   Tried that.  Like you, I keep getting "The specified user
domain class 'Person' is not a domain class".

I'm telling it I want to use LDAP.  It keeps looking for a table.

I haven't used the ldap plugin in grails, but I have set it up in a spring-mvc app in the past and it was relatively straightforward.  I don't know how much of the documentation of ldap from the spring-security docs you've gone through, but my guess would be that if you read through those docs, the grails plugin will be a lot less opaque to you - especially if you take a look at the plugin source code for clarification of what the plugin is expecting.

[mmorett]

Hi Samuel...

I'm getting closer.  Almost done in fact.

Yesterday's issue was entirely related to these two entries:

grails.plugins.springsecurity.ldap.authorities.groupSearchBase = 'ou=groups,dc=yourcompany,dc=com'
grails.plugins.springsecurity.ldap.search.base = 'dc=yourcompany,dc=com'

Once I substituted the proper values, it worked like a charm.   That said, it would have been preferable to see a "cannot contact LDAP server" error message or something similar.  The true problem was my LDAP settings in Config.groovy.  The error message did not indicate this. Even if the error message is technically accurate in some strange way, it wasn't entirely clear what failed and why.  The connection between some mystical Person domain object and my LDAP settings isn't intuitive (unless perhaps you're *very* familiar with either the plugin, or LDAP, or Spring Security, or all 3).

But....

:-)

...while login works and uses the LDAP server (with a good username/password), entering a bad username or password causes it to give me the dreaded "The specified user domain class 'Person' is not a domain class".

I'm still trying to figure that one out now.

Michael.

[mmorett]

Got it.  *wipes forehead*

The answer is you must use this entry: grails.plugins.springsecurity.userLookup.userDomainClassName

Seems obvious right?  Well, not so.  Let me explain...

In a pure Spring Security Plugin situation (with no LDAP plugin), you'd use that.  In fact, you'd use these three:

grails.plugins.springsecurity.userLookup.userDomainClassName = 'User'
grails.plugins.springsecurity.userLookup.authorityJoinClassName = 'UserRole'
grails.plugins.springsecurity.authority.className = 'Role'

So far so good.  This is very clear with Burt's documentation for the Spring Security Plugin.  The confusion arises when trying to use the LDAP plugin.  Since I wasn't going to use tables for this and would be using LDAP, the first thing I did was comment out those entries.

Bad move.

The LDAP plugin really wants a User domain object, at the very least for when authentication fails. It's fine without it if the username/password are valid. But it chokes when the username/password are invalid.  As to why it can't send you to the login page again to retry without the User domain object, I don't know.   This was just a Hail Mary pass on my part.  I got lucky.  The documentation was not clear (in the LDAP plugin) that this domain object is absolutely necessary.  Burt wrote both plugins so maybe it's clear to him, but mere mortals like us only have his docs to go on and this nuance is not clear.

Hopefully others can avoid this issue in the future...

Michael.

[ideasculptor]

On Wed, May 23, 2012 at 12:14 PM, mmorett <[hidden email]> wrote:

Got it.  *wipes forehead*

The answer is you must use this entry:
grails.plugins.springsecurity.userLookup.userDomainClassName

Seems obvious right?  Well, not so.  Let me explain...

In a pure Spring Security Plugin situation (with no LDAP plugin), you'd use
that.  In fact, you'd use these three:

grails.plugins.springsecurity.userLookup.userDomainClassName = 'User'
grails.plugins.springsecurity.userLookup.authorityJoinClassName = 'UserRole'
grails.plugins.springsecurity.authority.className = 'Role'

So far so good.  This is very clear with Burt's documentation for the Spring
Security Plugin.  The confusion arises when trying to use the LDAP plugin.
Since I wasn't going to use tables for this and would be using LDAP, the
first thing I did was comment out those entries.

Bad move.

The LDAP plugin really wants a User domain object, at the very least for
when authentication fails. It's fine without it if the username/password are
valid. But it chokes when the username/password are invalid.  As to why it
can't send you to the login page again to retry without the User domain
object, I don't know.   This was just a Hail Mary pass on my part.  I got
lucky.  The documentation was not clear (in the LDAP plugin) that this
domain object is absolutely necessary.  Burt wrote both plugins so maybe
it's clear to him, but mere mortals like us only have his docs to go on and
this nuance is not clear.

Hopefully others can avoid this issue in the future...

Thanks for posting a solution back to the list.  It's always nice when a google search turns up a solution along with folks looking for an answer to a similar problem.  I'd actually file a jira against this one as a feature request.  I can certainly imagine a scenario in which the security framework has to create some kind of user object when authentication fails, but it seems like it could/should use the same user object that it uses when authentication succeeds rather than falling back on the configured class.  It might be the kind of thing that is more of an oversight due to lack of exposure to the problem rather than something inherent to the architecture that would be a significant PITA to resolve.  It can't hurt to bring it to Burt's attention via a jira in case he can fix it quickly.  Also, the plugin code is often quite easy to comprehend. You might try taking a look to see if you can quickly develop a patch to correct it.  If my own past experience to go by, if you provide a patch that gets him most of the way there, or even a decent analysis of exactly what the problem may be, you'll often see a commit to the codebase within a day or two.

 

[burtbeckwith]

If you don't want LDAP failures to fall back to database lookups, remove the "daoAuthenticationProvider" bean from the provider list:

grails.plugins.springsecurity.providerNames = [
   'ldapAuthProvider', 'anonymousAuthenticationProvider', 'rememberMeAuthenticationProvider']

 

Omit "rememberMeAuthenticationProvider" if you're not using persistent remember-me. 

 

Burt 

 

On May 24, 2012 at 2:51 AM Samuel Gendler <[hidden email]> wrote:

> On Wed, May 23, 2012 at 12:14 PM, mmorett <[hidden email]> wrote:
>
> > Got it.  *wipes forehead*
> >
> > The answer is you must use this entry:
> > grails.plugins.springsecurity.userLookup.userDomainClassName
> >
> > Seems obvious right?  Well, not so.  Let me explain...
> >
> > In a pure Spring Security Plugin situation (with no LDAP plugin), you'd use
> > that.  In fact, you'd use these three:
> >
> > grails.plugins.springsecurity.userLookup.userDomainClassName = 'User'
> > grails.plugins.springsecurity.userLookup.authorityJoinClassName =
> > 'UserRole'
> > grails.plugins.springsecurity.authority.className = 'Role'
> >
> > So far so good.  This is very clear with Burt's documentation for the
> > Spring
> > Security Plugin.  The confusion arises when trying to use the LDAP plugin.
> > Since I wasn't going to use tables for this and would be using LDAP, the
> > first thing I did was comment out those entries.
> >
> > Bad move.
> >
> > The LDAP plugin really wants a User domain object, at the very least for
> > when authentication fails. It's fine without it if the username/password
> > are
> > valid. But it chokes when the username/password are invalid.  As to why it
> > can't send you to the login page again to retry without the User domain
> > object, I don't know.   This was just a Hail Mary pass on my part.  I got
> > lucky.  The documentation was not clear (in the LDAP plugin) that this
> > domain object is absolutely necessary.  Burt wrote both plugins so maybe
> > it's clear to him, but mere mortals like us only have his docs to go on and
> > this nuance is not clear.
> >
> > Hopefully others can avoid this issue in the future...
> >
>
> Thanks for posting a solution back to the list.  It's always nice when a
> google search turns up a solution along with folks looking for an answer to
> a similar problem.  I'd actually file a jira against this one as a feature
> request.  I can certainly imagine a scenario in which the security
> framework has to create some kind of user object when authentication fails,
> but it seems like it could/should use the same user object that it uses
> when authentication succeeds rather than falling back on the configured
> class.  It might be the kind of thing that is more of an oversight due to
> lack of exposure to the problem rather than something inherent to the
> architecture that would be a significant PITA to resolve.  It can't hurt to
> bring it to Burt's attention via a jira in case he can fix it quickly.
>  Also, the plugin code is often quite easy to comprehend. You might try
> taking a look to see if you can quickly develop a patch to correct it.  If
> my own past experience to go by, if you provide a patch that gets him most
> of the way there, or even a decent analysis of exactly what the problem may
> be, you'll often see a commit to the codebase within a day or two.

[wvetrone]

I have a question about grails.plugins.springsecurity.userLookup.userDomainClassName.  We have set that value in a config file in customized plugin (MyAuthPlugin) that wraps security core.  When we attempt to use MyAuthPlugin in an enterprise application the value for userDomainClassName is not found.  

This works when we are running Grails 1.3.7 but not when we are trying to upgrade to 2.1.  What am I missing?