Let say you have a User resource. It has many fields. However, not all fields should be allowed to updated by a regular user, but admins should be allowed. Are there any common solutions to this?
E.g. enabled should only be allowed to be updated by using a PUT request if the authorized user is an admin. How should I do this?
Have you heard of spring-security authorization? They have a way of hiding the fields based on the user roles. If your app is large, it makes sense to integrate this.
Lookup for methodlevel security
Domain object security (ACL)
Good article about entity filtering here
http://blog.dejavu.sk/2014/02/04/filtering-jax-rs-entities-with-standard-security-annotations/
Related
Is there any way to associate custom attributes with a Role in wso2? similar to the way we assign claims for profile.
I understand, we can associate Permissions to the user.
AFAIK, Roles cannot have claims in WSO2 environments. I doubt this is a common requirement. Anything that you are trying to achieve in particular?
Currently, it is not possible to maintain custom attributes with roles. Permissions are always associated to the roles and roles are associated to the user.
Thanks
Isura
I have configured a LDAP realm in Glassfish, and authentication works just fine.
Now I am wondering how could I match the Principal.getName() return to a certain attribute of my LDAP user object. I thought it would use something such as "givenName" by default, but it returns the username used for authentication.
I don't mind making an extra trip to the LDAP server to obtain the additional information, but instead of keeping the LDAP connection attributes in my application, I'd like to inject the security realm (if such a thing is possible) and use its own connection.
So, in short, the questions are:
1) Can I map additional attributes to the Principal returned by the realm?
2) If number one is not possible, then how could I reuse the realm's information in order to connect to the LDAP server and obtain the data I need?
Thanks in advance for any help or suggestions.
The JAAS Subject often contains many principals, each one representing a different attribute.
For Java EE one, and only one, of these Principals is selected for the one that is returned when you call HttpServletRequest#getUserPrincipal and similar methods. The other Principals are for the Java EE API just lost.
You can determine which of those Principals to select by writing a JASPIC authentication module if the login happens via HTTP or SOAP.
You can preserve the entire Subject by putting it into the HTTP session from within the JASPIC authentication module. Other code can pick it up from there.
Edited: I was under the impression that the following used to work, at least with GlassFish 4.0. Unfortunately, that doesn't (any longer) seem to be the case. A workaround can be found in the comments of this issue.
Not really a solution per se; just a little detail I kept overlooking for a while, and which was quite a relief for me to have now become aware of. So --skipping the boring specifics-- I realized that a CallerPrincipalCallback(Subject s, Principal p) constructor is additionally available, which, when supplied with my custom Principal, causes the server to actually retain it, instead of wrapping it in or transforming it into an internal GlassFish implementation instance, as I previously thought it would. From "userspace" I was then able to access my "enriched" (more Subject- than Principal-like, to be honest) version the usual way (e.g. ExternalContext#getUserPrincipal, etc.), cast it and enjoy the convenience of not having to care about deriving custom Principals from generic ones in each application from now on :) .
Well, I could not extend the Principal attribute mapping without using a custom LoginModule; so, instead I opted to the solution described here: http://docs.oracle.com/cd/E19798-01/821-1751/abllk/index.html
What I do is, upon authentication, use the injected LDAP context to go back to the LDAP server and obtain the attributes I want. The downsides are obvious: two trips to the server instead of a single one, and the extra code to probe attributes and tie them to the Principal (or another POJO) in some way.
The title tries to explain the scenario:
This customer has a login functionality that allows users with the same name but on different locations (stores).
At the login page the user informs userName, password and the required store.
Using Spring Security (with JPA) I created an UserDetailsService implementation but this interface always receive an userName (and the store was essential to differ from another users).
Giving this situation I have two questions:
How do I inform the spring security about the additional field? (store)
How do I implement an UserDetailsService with this info?
Is that even possible? I've been doing some research but the solutions weren't clear.
Thank you guys, you are the best =D
Your question is not all clear to me. Do you have a unique login for multiple stores? Then you don't need to give the store to your UserDetailsService implementation. I would simply load the user information using its username and if the users are not authorized for all the stores, you could use the GrantedAuthority to define where the users is authorized, e.g. ROLE_STORE_ID1, ROLE_STORE_ID2, etc.
If you have multiple stores where users are not shared, then you could simply create a configurable custom implementation of UserDetailsService, instantiate one per store and uses the correct instance depending on the store the user is accessing.
I hope this will help.
How do I conditionally serve different JSON objects from a Spring (3.1) backend? I am using Spring Security but I don't understand how I can serve different representations of an object?
I am only interested in the security logic, the other things I already have in place.
If a user named Sylvester is logged in with the role admin then he will recieve a bigger JSON object (more data) then a Arnold with the role user.
Do I have to use the authentication object see if the user has a particular role? Or are there some annotations or some other magic to do this?
In your logic you need to check current loggedIn user's role, and based on role you can return different response.
Yes you need authentication object, that must be implementing UserDetails interface and should have basic user info including its role/privileges.
This post seems to duplicate this question for the major part. Have a look at it and more precisely at this blog post, which gives a nice solution, but you will probably have to include or adapt 3rd-party code.
Still learning JSP Web Applications here.
I have been doing this for a while in my web application but I would like to know a more secured solution.
Imagine a Table that displays certain Book Information. When user clicks one of the rows in the table,
I basically send the BookID together with the url.
Example URL. http://locathost:8080/myapp/editbook.htm?bookID=3
in my servlet.
String strBookID = request.getParameter("bookID");
I think this is a little weak, is there a way where I could provide a more secure way other than this.
Its quite easier for hacker to edit the URL if I send the BookID together with the URL.
Can you share me some link on how to do this in both the Client Side and Server Side?
Thanks
I think this is a little weak, is there a way where I could provide a more secure way other than this.
You have to define "secure" on the basis of your application. The requirements are totally different for a public website selling books v/s a private library hosting confidential volumes v/s anything other application in between.
At a minimum, you should do the following -
Verify that bookID is in fact an Integer and is within an expected range.
Ensure that you bind bookid in a parameterized SQL Query - this is to prevent SQL Injection.
Show a 'Book not found' page if the book cannot be found
For a public website, the above is enough. You actually want people to discover your books, so if someone modifies the bookID, you shouldn't care.
For a secure library, you have to do a lot more.
Ensure that the URL is protected in web.xml, so only authenticated and authorized users can get to the URL
Verify the current user has access to the bookID. You can store the list of books available to a user in the session object.
If the user does not have access, return a 403 error page.
There are several other strategies to protect URLs; some use tokens to ensure the URL hasn't been manipulated. Others don't send bookID to the client, and instead rely on number {1 through n} where only the server knows that 1 corresponds to Book A and so on. But the idea is to ensure that a user doesn't get access to a book he doesn't have permissions to.
If you are using Spring, I'd highly recommend Spring Security. Otherwise look into JAAS.
You have to suppose that any user can send anything to you. The solution isn't avoiding users to send data in URL, it's to control that they can in fact do the following operation.
You need authentication and authorizations.
How to use authentication with your web.xml
Defining Security Requirements for Web Applications