I am trying to configure two UserDetailsServices for the authentication of two different user groups and I came across this post. However, it is using xml configuration, how would I accomplish the same using Java configuration?
As far as I know, the http element is configured by overriding the configure(HttpSecurity http) method, but how do I configure multiple http elements?
I do know that in many scenarios, it would be sufficient to have one UserDetailsManager which manages two user database tables, but I am curious how the other solution would look like in case I decide for it.
I do not see any reason for you to be using 2 UserDetails implementations, as you are saying you need to authenticate two different user groups. Would suggest to look at http://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle/#authorization and think would give you a lot of pointers where you should go from there.
What you are in need is upon authentication in system to know what the logged in user Role is and define it. Two ways are indeed one via xml second is Annotation based in a #Configuration java class with the specifics laid out there. Read up the above link I posted for you and you should be able to see what Spring offers and what you are in need to do actually.
Would take a lot of space First to put it down and Second it is a very broad question you are asking as the post link you are referring to is incorrect in the way it handles Spring Security.
Related
I am currently developing a REST-application which needs to be very scalable. From what I have learned about load balancing, one should split up the actual application into independent parts. So far I've separated creating accounts and the login from the actual application. I followed this tutorial to implement JWT. Is that best practice or can this solution be improved?
However, I have my actual REST-application as a separate project. Obviously, these two applications need to work together. How can I accomplish that? Is there a way to store the Token & access it in the second application?
I really appreciate your help!
You need to follow microservices architecture. This example has end to end description of what you wanted.
Since, what you needed to implement is of very large scope, you can ask us in case youu have any issue with the MicroServices Architecture.
Cool!
I wanted to use the OSGi User Admin service for security but I could not get enough resource about it.
I want to authenticate certain bundles that will be installed in the system and represent them by User-Objects after authentication. So that I can later use these User-Object for authorization.
I have 2 questions:
Since I have more than one user, how can I know which bundle is calling a secured method? (I don't want to pass the user object as a parameter to every method I want to control).
How can I relate the bundles with the User-Object representing them?
I want to have one bundle as an entry point that will authenticate all these other bundles and have control over them. But I couldn't even find anyone mentioning using User Admin service. Is there another option for OSGi security besides CPA? I would like to use this to secure my console as well.
That's quite a few questions rolled into one. Let me try to answer them all.
First of all, the UserAdmin service is specified in the OSGi compendium. There, it explains how users, roles, etc are defined and how you can use the service to answer questions like "does this user have role X"? What that does not tell you is how to use this service as part of a security solution. That's up to you.
Regarding question 1, which is not an OSGi related problem (but rather a generic one in Java applications), there traditionally have been a few methods of passing on a "context" to a method:
Making it an argument to each method (which you do not want to do).
Storing it in the ThreadLocal context (which is fairly popular in JavaEE, but has its downsides if your application delegates work to threadpools that might or might not pass on such a context correctly).
If this is all about security for services that you implement yourself (and not third-party ones) you could use the ServiceFactory pattern in OSGi to give each client bundle it's own context (and embed the User object in there; for examples look at the LogService implementation in Felix, which uses that mechanism to add a bundle.id to each log message).
Sometimes it also makes sense to embed the context not in an extra parameter to your methods, but as part of some existing object (so effectively you are then associating the context with specific objects, which might or might not make sense depending on your domain).
Another option would be to use the Apache Felix Dependency Manager to intercept the services you want to secure (with an aspect) and, in the aspect, figure out what bundle is calling, and do the proper security checks (probably requires a more detailed answer if you want to give that a go).
Regarding question 2, bundles have a symbolic name that identifies them. You could use that to associate a bundle with a User. There are other options, but this is the most obvious one.
Regarding your question about options for OSGi security, I would say ConditionalPermissionAdmin (and the older PermissionAdmin) is the only solution to address security within the OSGi framework itself, if you want to specify what specific bundles can and cannot do in terms of importing packages, using services, accessing the filesystem, etc. You would have to write your own custom permissions if you want to integrate this with UserAdmin.
Finally, the secure console is yet another thing you need to address yourself. You might be able to find some building blocks as I know there have been people implementing some role based access (David Bosschaert comes to mind). However, the console is a complex and powerful thing, so answering this question alone takes more than a simple SO question because it depends what and how fine grained you want to implement this.
Here is the summary: I need to build a simple java web app that, among other things, will let the user create, update, delete, and view records from a few tables.
My app is required to use Struts2 and the struts2-jquery-plugin to implement AJAX functionality (grid).
However, I'm new to Struts2 (and Java in general), so I've being trying to follow tutorials all over the globe. And the more I search, the more I find different solutions and plugin dependencies which means more tutorials to read. I've written everything from business, dao, and beans but the .jsp's and actions. I'm now short on time and can't spend another week on wrong directions. Hope this thread can save someone else time too.
Questions:
1- I've downloaded the showcase examples and they all seem to use hibernate plugin. Is it a MUST or can I use grid without it? Because it's too much info for a single human head at this point.
2- Related to sessions. Do I need to configure an interceptor to be loaded at every action call to check if user is logged in, or is there anything taking care of this by default in Struts2? I'm trying to avoid struts.xml, so I'm using convention. How can I achieve this session check without xml configs?
3- If anyone can provide some short and fast examples of using struts2 and grid, it'd be really appreciated.
More questions should come shortly.
My 2 cents: always use KISS (Keep It Simple, Stupid) pattern, especially if you are new to Struts2, JSP and Java in general...
I recommend to start with little things. Login Action, First Action, First JSP.
When all works (you can read data from DB through First Action and display it on First JSP), you can go deeper (EJBs, Interceptors, Validation, etc).
By the way, for Session Checking Interceptor, take a look here
(You put a boolean on login page, you check it from the Interceptor, then you can forget about it, instead of checking it on every Action...)
I've a webservice written with Spring MVC for a webapp.
The user could change the locale and so the language of his page, so a call to my webservice is done with this information. For information, at startup, I load few beans for my webapp configuration. These beans attributes needs to be internationalize
My question is how can I update the values of my bean directly from a user call ?
There are two things here:
One is overall i18n architecture. At best Beans (controllers, models) should not contain any translatable texts, therefore no i18n work would need to be done to make them localizable. This is ideal situation which doesn't happen to often in practice.
Another is a way to make Controllers localizable. Again, there are two possible approaches: one is to use resource keys instead of strings, messages, etc. and resolve it in your View to real translation, just before displaying it to user, another is to make Controllers read these messages from resources - you said that you know Locale, so it could be done. If you are going with latter solution, you probably need to limit your Scope to request (as different users might want to use different languages and as far as I understand what you wrote users might want to change their language on the fly).
I have a concern when it comes to GrantedAuthority objects in a Spring Security application. I'm looking for a good way to handle things. First of all I'm trying to describe my concern, if there are any factual errors do not hesitate to point them out, I'll only be greatful.
Spring Security uses GrantedAuthority instances to act as tokens of authorization in different parts of the application.
By default a GrantedAuthority may present itself as a String. When methods are secured using #Secured("ROLE_NAME"), or URL's are secured using the Spring XML configuration or when the HttpServletRequest request is checked programmatically as in if(request.isUserInRole("ROLE_NAME")) {..} it's always the String that you are using to specify the authority which is checked for.
I'm wondering about the implications of using static strings in several places of the application. If a role name is changed the developer has to hunt down all the old strings and update them. There will be no compile time error if a String is missed, only a problem at runtime.
What is the best way according to you when it comes to handling GrantedAuthority objects in a Spring Security application? What pros and cons does your solution have?
First off, if possible, only do your checks at a particular place in the application (e.g. an HTTP interceptor at the beginning of the request), and using only one of the mentioned approaches. This is a good practice since you will be able to know authoritatively when a user becomes authorized.
If this is not possible, use enums for the role names and only compare on the enums. Therefore, if you wanted to locate all usages in the application it's a simple search.
I do not see a big problem here. It is very unlikely for GrantedAuthority to change the key. Just do not name your roles ROLE_A.
Also, I personally prefer XML security configuration over annotations. In general to keep any related configurations in one place looks like a good idea.
In Spring and other frameworks (especially for dynamic languages) "Convention over Configuration" is used. If you were free to define the role names yourself, you easily find out that much more lines of code are needed.
So stick to the convention. Always use the 3 following roles, ROLE_ANONYMOUS, ROLE_ADMIN, and ROLE_USER. If you need another one, name it accordingly and use it in all occasions. Documentations is important.
Also unit testing is imported. It helps you in the cases that an error isn't caught by the compiler.