s2-quickstart and UserDetailsService

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

s2-quickstart and UserDetailsService

tmarthal
When I ran the s2quickstart it generated a MyUser domain class which did not subclass any other classes (it also generated MyRole and MyUserMyRole base classes).

However, when I start to use the security tag <sec:loggedInUserInfo field="myField" /> I must specify a UserDetails service to get the extra 'myField' value. The UserDetails service must implement the two methods

   UserDetails loadUserByUsername(String username) throws UsernameNotFoundException
   UserDetails loadUserByUsername(String username, boolean loadRoles) throws UsernameNotFoundException

which return instances of the 'org.springframework.security.core.userdetails.UserDetails' class. The MyUser domain class does not extend that class.


Do I need to re-factor the whole set of classes that was generated with the s2-quickstart to inherit from the UserDetails (or GrailsUser) class? Should I use GrailsUser as a reference? Using this UserDetails mechanism, it seems that we need to use the authorities list directly rather than using the generated domain model for the user::role mapping.

Is there a way to use the s2-quickstart domain models in a UserDetails like service?
Reply | Threaded
Open this post in threaded view
|

Re: s2-quickstart and UserDetailsService

Burt Beckwith
Administrator
Spring Security uses an instance of UserDetails as part of the Authentication. It doesn't care where the data comes from to generate it, so you can load it from a database, or OpenID, a web service call, etc. The plugin uses a custom UserDetailsService that uses the User, Role, and UserRole domain classes to retrieve user and role data but the domain classes are otherwise unrelated to the UserDetails and UserDetailsService implementation - there's no benefit of subclassing or interface implementation.

If you want to display information with the <sec:loggedInUserInfo> tag from the User class that's not in the UserDetails instance, you need a custom UserDetails implementation and to extract the extra data at authentication - currently only the username, id, and role names are used. See section "11 Custom UserDetailsService" in the docs for the approach to use.

Burt

> When I ran the s2quickstart it generated a MyUser domain class which did not
> subclass any other classes (it also generated MyRole and MyUserMyRole base
> classes).
>
> However, when I start to use the security tag <sec:loggedInUserInfo
> field="myField" /> I must specify a UserDetails service to get the extra
> 'myField' value. The UserDetails service must implement the two methods
>
>    UserDetails loadUserByUsername(String username) throws
> UsernameNotFoundException
>    UserDetails loadUserByUsername(String username, boolean loadRoles) throws
> UsernameNotFoundException
>
> which return instances of the
> 'org.springframework.security.core.userdetails.UserDetails' class. The
> MyUser domain class does not extend that class.
>
>
> Do I need to re-factor the whole set of classes that was generated with the
> s2-quickstart to inherit from the UserDetails (or GrailsUser) class? Should
> I use GrailsUser as a reference? Using this UserDetails mechanism, it seems
> that we need to use the authorities list directly rather than using the
> generated domain model for the user::role mapping.
>
> Is there a way to use the s2-quickstart domain models in a UserDetails like
> service?
>
>
> _______________________________________________
> If you reply to this email, your message will be added to the discussion below:
> http://grails-plugins.847840.n3.nabble.com/s2-quickstart-and-UserDetailsService-tp2840807p2840807.html
> To start a new topic under Grails Plugins, email [hidden email]
> To unsubscribe from Grails Plugins, visit
Reply | Threaded
Open this post in threaded view
|

Re: s2-quickstart and UserDetailsService

tmarthal
Your answer as well as working on it that last 5% made it click.

I was thinking that the same grails generated user domain model would be the same one that would be used in the UserDetailsService. Creating a new CommandObject which extends GrailsUser being populated with the generated user domain model works well.

Thanks.