Suppose in one application we have interface(UI) to assign roles.
First scenario:
So to say user A who is normal user. And one admin assigns him ADMIN role using UI.
Now when user A logins the application then he can see all the tabs which can be accessed by ADMIN.
Second scenario:
In the same time (when he is logged in and have session with ADMIN role), admin makes user A as normal USER who have normal privileges.
But as he is login as ADMIN so he can access all the admin information for all the tabs as in this session he has ADMIN role.
How I can solve this problem??
The first approach would be to expire any existing user sessions on the on the fly.
the following post describes two alternatives Is it possible to invalidate a spring security session?
A more sophisticated approach would be to flag the use in a list when his authorities changes.
Here is a good example Implementation of singleton thread-safe list
Furthermore, if you add a custom spring security filter which checks if the user is in the list and if necessary reauthenticates the user. I would use the switchuserfilter as a reference implementation. Instead of switching a user, you create a new authentication object and update the SecurityContextHolder.
All the necessary logic should be included in http://docs.spring.io/autorepo/docs/spring-security/3.0.x/apidocs/org/springframework/security/web/authentication/switchuser/SwitchUserFilter.html
Related
I'm using Grails 3.3.5 and org.grails.plugins:spring-security-acl:3.2.1.
Is there any way to easily rebuild Authentication (including authorities) for non-current user on fly?
The issue is the following: admin grants user a role, but the role is taken into account only after user's relogin.
Is there any analogue like springSecurityService.reauthenticate(...) but for non-current user?
No, it's not possible, unless you replace the default http session mechanism with some centralized cache, allowing the admin to change session attributes for any arbitrary user on the fly.
I am using the spring security plugin and thus am able to make use of the method springSecurityService.currentUser to access the current logged in user. However, i assume that obtaining the current user within each controller action and then performing actions based on the returned user is not the recommended best practise.
Examples:
logged in user clicks link to their profile page - controller obtains current user and returns data to populate profile page for this user.
logged in user changes status on profile page - controller obtains current user, from this finds their profile and then updates the status on this profile.
ETC
This should ensure that a user accessing a page is who they say they are - as there is no passing of User Id or other identifying information from a client. However, obtaining the user in each action seems wrong, and i havent seen many examples of code which do this. Should I be using filters to intercept requests or some other flow/practise?
springSecurityService.currentUser exists for that exact purpose. The reason you need to retrieve the current user each time is because controller actions are stateless. Yeah, there's a session at play which maintains some state, but what I mean is that there's no direct transfer of state from one controller action to another. So, it is in fact best practice to obtain the current user each time.
What happens is the client provides a cookie, usually named JSESSIONID, to Grails. Grails then uses that to restore any session data, which essentially leads to springSecurityService.currentUser being able to provide the current user. So while the client does not pass the user ID, it does pass a session ID, which indirectly is identifying information.
I have an asp.net mvc application. I have administration page to manage users. Have a scenario where admin adds new users and those uses have its own logins. Say admin creates a user 'testuser' and the testuser logs in to the application. Meanwhile admin deletes 'testuser'. The every next click of 'testuser' must redirect to login page. How can this be done? Is this managed through web.config, or whether this can be managed using the Base Controller(All controllers inherit from Base Controller).
I'd create an overload of the AuthorizeAttribute class where you'll check the database for every request wheither the user is still allowed to be logged in in the administration page.
I don't know what your requirements are with regards to the amount of users that will use the administration section, but this can become heavy on the database to have an extra database call on every authorized action.
To Whom it may concern
I would just like to know is possible to use one user name and it be used by multiple users at the same time on sitefinity without it kicking out a logged on user when another another user logs in using the same user name.
Kind Regards
If the user has a backend role then he will not be able to login concurrently from different machines/browsers. He will have to terminate the existing session before starting a new one.
Frontend users do not have this limitation.
Let's say I have users and articles.
Anonymous can list and read articles.
Only registered and logged user can create articles.
User can edit only own articles.
And, of course, admin can do anything.
I've looked at spring security, but didn't found a way to do that. My app don't need roles, and ACL will be too "heavy" for that.
Maybe I should implement my own security?
You're right, ACL would be too much for the task.
You can use Spring Security's authorize tag in JSP, which provides access to the logged in user via the principal object. Example to limit access to editing an article to the user with a given username:
<sec:authorize access="hasRole('SOME_PRIVILEGE_OR_ROLE') and ${someArticle.username} == principal.username">
...
</sec:authorize>
Note that SOME_PRIVILEGE_OR_ROLE could be some role like 'LOGGED_IN_USER', but could also rather specify a certain privilege, e.g. 'READ_ARTICLE' or 'UPDATE_ARTICLE'. Spring Security is flexible here. Whatever you choose, it needs to be in the GrantedAuthorities collection of your user object.
Note also that you can implement your own user object, adding further info to what the UserDetails interface provides, e.g. comparing the user's id rather than the username.
Finally, note that you need a recent version of Spring Security (>=3.1) for the Spring EL to work as in the example.