CODEWITHSUNDEEP
spring-security
hguser
hguser

Reputation: 36028

the role and permission in spring security 3

I am new in ss3,and I have read its reference,also I read the spring security book.

However I do not find anything about the role-permission.

For example,here is the config for form-based authentication.

  <http auto-config='true'>
    <intercept-url pattern="/user/add/**" access="hasRole('USER_ADMIN')"/>
    <intercept-url pattern="/user/delete/**" access="hasRole('USER_ADMIN')"/>
    <intercept-url pattern="/login.jsp*" access="IS_AUTHENTICATED_ANONYMOUSLY"/>
    <intercept-url pattern="/**" access="ROLE_USER" />
    <form-login login-page='/login.jsp'/>
  </http>

I want to control the user operation(add/delete):

<intercept-url pattern="/user/add/**" access="hasRole('USER_ADMIN')"/>
<intercept-url pattern="/user/delete/**" access="hasRole('USER_ADMIN')"/>

I define the role of 'USER_ADMIN',but this is not enough,since I want to differ the user who have 'add' permission from user who have 'delete' permission.

Maybe I can add more roles like 'user_admin_add' and 'user_admin_delete'.

But I do not think this is a good idea since the 'add' or 'delete' are permissions,not roles.

How to make it?

Also,it seems that all the roles should be configed to the xml file,I wonder if I can add new roles and permissions dynamically(in the administrator page)?

Upvotes: 4

Views: 5704

Answers (4)

ssedano
ssedano

Reputation: 8432

Think of roles as a privileges. And granulate them as much as you need. Another thing is that maybe you should make a more RESTFul implementation. But this is another thread.

For example, your "delete" could be a "DELETE" HTTP method. Then you could be:

<security:intercept-url pattern="/users/*" method="DELETE" access="ROLE_DELETE_USER" />

and a curl -X DELETE -u login:password 'http://example.com/users/1'

would delete the user with id 1.

By a RESTFul, since uris are either identifiers or actions, there is no use in add roles (privileges) dinamically. Since those roles are meant to be used against a new resource that should contain the xml file.

I'm afraid you cannot do this, unless you use ** wildcards. Which in my opinion if used uncarefully can lead to troubles.

Upvotes: 3

Simeon
Simeon

Reputation: 7792

Maybe I can add more roles like 'user_admin_add' and 'user_admin_delete'.

This is the way. Permissions are roles and generally there are people who view differentiation between them as unneeded.

I don't think there is much difference in having a role ROLE_USER_ADDER or a permission PERMISSION_ADD_USERS.

You can however use roles as a concept to group permissions if you need to. For instance you can have a role admin which can add and remove users. So the role ROLE_ADMIN will have PERMISSION_ADD_USER and PERMISSION_REMOVE_USER. Still spring will view both roles and permissions simply as authorities.

As for dynamic roles adding you can do it by loading the current user permission from your DB for instance. Have a look at the UserDetailsService of spring security. The UserDetails object it returns has a getAuthorities() method which you can populate from your DB.

/**
 * Returns the authorities granted to the user. Cannot return <code>null</code>.
 *
 * @return the authorities, sorted by natural key (never <code>null</code>)
 */
Collection<GrantedAuthority> getAuthorities();

Here is a very good example of implementing your own UserDetailsService.

Upvotes: 3

Ralph
Ralph

Reputation: 120781

In my personal opinion spring security has several (lets say) unfortunately chosen names. So do not pay so much attention to the Term "Role" it works perfectly if you use it for privileges.

In my applications a use a naming convention to choose between Roles ans Privileges. (roles are written upper case, privileges lower case). But pay attention the Role Voter will pay attention only the the strings that starts with "ROLE" (Default configuration, can be changed.)

See also Spring security group based authorization

Upvotes: 2

ptomli
ptomli

Reputation: 11818

You should be thinking of roles more along the lines of, well, roles, rather than permissions. If you want to differentiate between adding and removing users, you might define roles described as ROLE_SALES and ROLE_USER_ADMIN. Sales staff might well need to be able to add new users into a system.

Regarding the dynamic application of roles, you should look at the architecture of Spring Security. You'll most likely want to use, or implement, a suitable UserDetailsService. See the UserDetailsService reference documentation.

If you're storing your user authorization information in a JDBC database, for example, you might want to use the JdbcDaoImpl.

There are some examples of using different authentication providers in the namespace introduction.

Upvotes: 0

Related Questions