spring security : Accept terms and conditions after login - spring

I have a use case to make the user accepts terms and conditions after login. The user cannot access any URL after login unless he accepts the terms and conditions. Is it possible to implement the same using spring security? If yes, how?

It is possible to add user one privilege after successful login, and just allow him to access terms and conditions page (ex. TERMS_AND_CONDITIONS_PRIVILEGE). After success post with accepted terms you can get permissions for user from database and grant it to his security context. Here is nice post how to do it
http://forum.spring.io/forum/spring-projects/security/60663-change-user-logged-authorities-on-the-fly
First you have to get SecurityContextHolder by calling SecurityContextHolder.getContext() Next you have to get Authentication from it by callingcontext.getAuthentication(). From Authentication you can get Principal and cast it to User object.
Remember to check if SecurityContextHolder.getContext() does not return null value and also if Authentication a = context.getAuthentication() is not null.
I also recomend to check if a.getPrincipal() is instance of User class
I hope it helps

I'd suggest to add check box in the login page. This check box will be checked when user acceps terms & conditions. The login page will be a JSP, so upon submission, you can check if the check box is checked, meaning the user has accespted the terms and conditions.
It is simpler to implement (you do not need another redirect), and I think it is better UX (user experience).
HTH.

Related

Spring boot MVC - Block users from seeing endpoints by changing id in url

I'm writing a pretty simple ecommerce app with spring boot and thymeleaf and I found out that users can see any order by changing the id in URL.
For example:
User placed an order with ID 5, so he can see his order on url: /order/details/5
But if the user changed url to f.e /order/details/4 he can see details of order that he shouldn't be able to see.
Is there a simple way to block it with Spring security?
First off, let's get some lingo out of the way:
Authentication - The act of proving someone's identity. E.g., you login with a username, but you need a password to prove that it's you.
Authorization - Is the act of granting a user permission to perform an action.
Those terms are important when reading the Spring Security Documentation.
I assume that you already authenticate user and now you want to authorize them to view, e.g., their own orders, but not those of other users.
But I guess the orders are stored in a database. So you'll probably have to authenticate in your service layer. Meaning Spring Security takes care of authentication and you have the user available. When you fetch some order, you also need to make sure that the authenticated user is the owner.
Another thing to consider is using UUIDs as primary key. That makes it much harder to guess an ID but this is absolutely no replacement for authorization! Seriously. It is not. Security by obscurity is broken.

Allow admin user to login as other users

Is there any way to login other users account for admin user ?
Currently authentication based on Meteor Accounts
I saw this post but didn't working at all now.
The feature is important for us because when user have problem in system then admin need to see it this by simulating user account.
Thanks in advance.
It seems you want to impersonate a user. This means that you want to have Meteor.userId (or this.userId depending on context) reflect the _id of a specific user both on the client and the server.
afaict the only way to do this is to login as the user. Presumably you don't want to ask the user for their password so you have a couple of choices:
Save their existing password, replace it (temporarily) with a password of your choosing, then after you're done impersonating their account, restore their existing password.
You probably don't want to ask the user for their password and you don't need to. All you need to do is set aside Meteor.user.findOne(userId).services.password.bcrypt, then reset the password to your temporary value, then restore the original bcrypt value later.
The downside is that the original user would not be able to login while you are logged-in. Plus it's really hacky.
Extend Meteor's Accounts package to provide impersonation capability in a more elegant manner.
You might also look at validateLoginAttempt. The docs are unclear as to whether a failed login attempt could be overridden with a successful one but if it could then that would provide another pathway to solve your problem.
Instead of logging in as the users, which requires their password and which is a total no-no, you may use rather alanning:roles and allow the admin to assign the role of any user in order to draw views based the user's role.
This requires a well designed role system.
As a plus you could then at least load the documents associated with the user who you want to support.
This requires a well designed document and data model.
But generally spoken you should rather focus on writing good tests (test driven development) for components as unit tests, integration tests and UI tests.
This will reduce the need to manually view the app as an end user a lot.
The most common end user problems can be reduced by creating a good knowledge base like a wiki or video tutorials.
Even if then an error occurs in the end user side, I would rather try to implement a well designed error log that allows users automatically create tickets on error which also include the error stack.
All the above methods are to be favored before logging in AS THE USER.
As #Jankpunkt has already mentioned alanning-roles I can add something you can use without installing any external package.
Just keep a type key in the profile object of the users collection. Then define some types like 1 for super-admin, 2 for admin, 3 for general etc. Then check the authorisation of particular action by checking the value of user.profile.type key.
Caveats: Make sure you are checking the type in server side. By default profile field is writable from the client end, so if you are putting type field in the profile object make sure that you are not allowing users to modify users collection in the client end.
Here is how to restrict client end update in users collection:
Meteor.users.deny({
update() { return true; }
});
Read more on roles and permissions here:
https://guide.meteor.com/accounts.html#roles-and-permissions

Validation in Spring with different Roles

I'm just trying to understand the "Validation" within Spring MVC. I set up a small validation form, which is working just fine. However I got a couple of questions all those Tutorials don't answer
As far as I understood the Validator just gets every form-element altered and checks if it is valid or not. What if I want a user to only be able to alter specific form-elements.
Let's say I have an Admin and a regular User on my webpage, they both are allowed to edit their profiles. The admin however is allowed to alter his username, the regular isn't allowed to do that. They both use the "edit-profile.jsp" and therefore the same Validator. I could just grey out the username field in my regular user's view, but let's assume he's not a total BDU and adds a form-field via debugger of his webbrowser, overriding the actual username input-field. He then alters his username and sends the request to MVC. The validator assumes the username altered came from the original input-field and updates the user's nickname in the db accordingly, since both, the admin and the regular user just use the same Validator and the same "updateAllAltered"-DAO method. The same goes for select option-lists. Let's say the Admin is allowed to set a status of a profile to active AND inactive. The user however is only allowed to set it's own profile to inactive but can't reactivate it by himself. I could do the same as above, just altering the option-panel in the frontend to only show "INACTIVE" in the regular user's dropdown box. But we could repeat the same scenario, where the user just adds a debug form-field containing also the option "ACTIVE". This can get out of hand if e.g. the Admin is allowed to change Roles to "admin, member, moderator", while a user, who's i.e. a moderator within a forum can change roles to "member or moderator". He could just again add another field and plugin "admin" and gain total control of the forum.
How is this handled in Spring?
Basically you have to handle by spring security for your use case, design your application security, you will find basic spring security examples easily.
Example you can block your HTML code in JSP by spring security tags by user roles.
<sec:authorize access="hasAnyRole('ROLE_ADMIN')">
Delete
</sec:authorize>
You can annotate any of your methods by roles to block access.
#Secured({ "ROLE_ADMIN" })

check for username against password in base controller mvc 3

I want to know how can I force a user to log in the the application again if the page is being opened in new tab or new browser.
Edit:-
My apologies I misunderstood the requirement.
I am authenticating the user in my log-in page but not anywhere else. So what is happening because of that, even if i log out of application and type url say bla.com/apple I can access my application.
I figured to prevent this from happening, I have to write a base controller that checks for the right user. Am I moving in the right direction.
Thanks
Addressing the edit -
Authentication can be handled per controller or on individual actions. Simple place the [Authorize] attribute appropriately. This assumes however that somewhere an authentication token is being set. [Authorize] checks against the HttpContext's current User (an IPrincipal).
You mentioned above that you're just validating against a local username and password, in one place, so I'm guessing that no token (session, cookie) are being set?
You have a few options here to get that token stored and persisted across requests:
ASP.Net integrated membership provider (Intro)
A custom MembershipProvider (Example)
Full-on custom flow. (Example)
Each has ups and downs and depends on how exactly you want to handle on-boarding your users. It's hard to answer more specifically because it can be a very large topic (and a very broad question).
Here's the official pages for MVC security.

How to change granted role temporarily to achieve "view the site as" someone else

We are using 2.x spring security right now. I am asked to build an admin tool so that the ROLE_ADMIN can change to any user in the site and view the site as that person (each person on the site may see different stuff depending on the role which is dynamically granted base on the database) and of course the admin should be able to switch back to admin without logging in.
Is there a build in function, if not how should I do this?
Thanks in advance!
Use the existing Spring SwitchUserFilter:
http://static.springsource.org/spring-security/site/docs/3.0.x/apidocs/org/springframework/security/web/authentication/switchuser/SwitchUserFilter.html
I don't know any spring-security out-of-the-box solution that will answer your requirement, but I can suggest you a way for implementing it.
Declare a url for the "view the site as" action with a query param to get the user name, for example: /myApp/viewTheSiteAs?user=marley
Write your own custom filter that will do the following:
2.1 Validate that the authenticated user is "admin" user
2.2 Extract the user from the action ("marley" :-))
2.3 Validate that it exists (using the UserDetailsService).
2.4 Construct new Authentication object with the granted authorities that fits the user you have extracted, and replace the current Authentication object with your own object: SecurityContextHolder.getContext().setAuthentication(myNewAuthObject)
Add a filter chain in spring security config file for /ViewTheSiteAs that will act as regular filter chain (should authenticate the "real" user as regular), and locate your custom filter at the end of the chain.
Doing the following will cause spring security to think that the user from viewTheSiteAs action is the authenticated one, and by that check the permissions according this user.
p.s. - this is not a security break since it downgrades the authenticated user permissions, which means "less powerful" user.
Good luck.

Resources