6

I'm trying to convert a Stripes web app to Grails. The Stripes app uses Spring Security, but I would like the Grails app to use the Spring Security Grails plugin.

The app already has User and Role (Java) classes that I need to reuse, i.e. I cannot use the Grails domain classes that the s2-quickstart script generates.

The Spring Security plugin docs describe how to use an existing User domain class. The steps seem to be:

  1. define a UserDetails implementation that reads from the existing User domain class
  2. define a custom UserDetailsService implementation that returns instances of (1)
  3. register an instance of (2) as a Spring bean named userDetailsService.

However the docs don't provide any information about how to use an existing Role class and the class that represents the many-to-many relationship between User and Role.

What other steps are necessary to use existing Role, User, and UserRole classes with the Grails Spring Security plugin? Is there any reason for me to run the s2-quickstart script if I don't want to generate any domain classes?

Follow-Up Questions to Burt's Answer

In the end, what you need is a new GrailsUser

Presumably GrailsUser here refers to the custom UserDetails implementation? In my case I'll probably just implement the interface directly. Does something like this seem reasonable?

class UserAdapter implements UserDetails {
  private String password  
  private Collection<GrantedAuthority> springRoles

  UserAdapter(User user) {
    this.password = user.password

    Collection<Role> roles = // load legacy Role objects
    this.springRoles = roles.collect { new GrantedAuthorityImpl(it.authority) }
  }      

  // If using password hashing, presumably this is the hashed password?
  String getPassword() {
    password  
  }

  ///////// other UserDetails methods omitted

  Collection<GrantedAuthority> getAuthorities() {
    springRoles
  }
}

I'm not storing the whole User object within UserAdapter because of your warning about storing a potentially large object in the HTTP session.

what you need is.....and a List of GrantedAuthority instances (and the id if it's a GrailsUser)

If I use my own UserDetails implementation as above, then presumably I can ignore this comment about providing an id?

Finally, if I follow the approach outlined above, should I set these properties in Config.groovy and do I need to run the s2-quickstart script (or any others)?

Community
  • 1
  • 1
Dónal
  • 185,044
  • 174
  • 569
  • 824
  • 1
    That looks good. You could calculate the role -> GrantedAuthority in the UserDetailsService and then use the Spring Security User or plugin's GrailsUser as a POJO, but this is fine too. Yes, it's the hashed password from the db. The cleartext password will be encrypted and compared to this. The role stuff looks good, and obviously you'll need the boolean getters. I keep the id in the UserDetails to make re-loading the source User easy, but if you don't need that then omit it. You can also use the username, it'll most likely have a unique index and be nearly as efficient as a PK query. – Burt Beckwith Aug 02 '11 at 22:38
  • 1
    If you're using a custom UserDetailsService, then the class names in Config.groovy aren't used since that's just for the plugin's UserDetailsService. s2-quickstart will give you the login/logout controller and GSPs, so you might run it with a dummy package and delete the generated domain classes. – Burt Beckwith Aug 02 '11 at 22:39
  • Thanks again, very helpful. One very last question, you said that "I keep the id in the UserDetails to make re-loading the source User easy". How do you know when to reload the User within UserDetails? I'm assuming you don't do it every time a method is called? – Dónal Aug 02 '11 at 22:58
  • It's not from the UserDetails, it's typically in a controller request after initial login. The UserDetails is easily accessible since it's the Authentication 'principal', so if the id is there you can get the User via 'User.get(principal.id)'. You can also do 'User.findByUsername(principal.username)' though, but as I said, it's only efficient if there's an index on username. – Burt Beckwith Aug 03 '11 at 03:57
  • Got it, in my case there's a unique index on username, so there's no need for me to add the `id` to user details. I think there may be some caching benefit to using the `id` instead of the `username`, but for the moment I'm more interested in getting things working than optimizing performance. – Dónal Aug 03 '11 at 08:36

2 Answers2

4

Keep in mind that Spring Security doesn't care where the data comes from, it just needs a UserDetails instance when authenticating with the DAO auth provider and it can come from anywhere. It's convenient to use domain classes and database tables, but it's just one approach. Do what works for your data. In the end, what you need is a new GrailsUser (or some other impl) instance with the username and password set, the 3 booleans set, and a List of GrantedAuthority instances (and the id if it's a GrailsUser).

The simplest thing to do when you have legacy user and role data is to create a custom UserDetailsService. Use GORM, raw SQL queries, whatever you need to get the required data.

Another option is to write your own AuthenticationProvider like Glen did here: http://blogs.bytecode.com.au/glen/2010/01/15/hacking-custom-authentication-providers-with-grails-spring-security.html - although that's a larger solution that also involves a custom filter which you wouldn't need. The DAO provider uses a UserDetailsService but it's fine to create your own that combines the functionality into one class.

It's not a good idea to reuse your User domain class as the UserDetails though. Even if you implement the interface, you'd be storing a disconnected potentially large (if there are attached collections) object in the HTTP session. The POJO/POGO implementations (Spring Security's User class, the plugin's GrailsUser class, etc.) are very small and just a few Strings and booleans.

Burt Beckwith
  • 75,342
  • 5
  • 143
  • 156
1

within the config.groovy file you have to specify your domain classes to use:

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

i thinks it's not neccessary to implement your own userDetail service, because spring security uses

SpringSecurityUtils.securityConfig.userLookup

method to determine the domain class you configured before. your domain classes must provide the required fields and relations.

hitty5
  • 1,653
  • 12
  • 25
  • If your User domain class already implements `UserDetails` you probably don't need to provide your own `UserDetailsService`, but in my case it doesn't – Dónal Aug 02 '11 at 15:14