use existing domain classes with Spring Security plugin
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:
- define a
UserDetails
implementation that reads from the existingUser
domain class - define a custom
UserDetailsService
implementation that returns instances of (1) - 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) }
} 开发者_Go百科
// 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)?
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.
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.
精彩评论