In my Spring Boot application, I have several roles that are differentiated due to a token. Each one has a different token in the configuration file (.properties or .yml), which is then read by a JWT management class.
Initially I thought to do this just for one controller, but it makes sense to apply this logic to others as well, so I would like to ask what you guys recommend for this type of case.
After a little searching I found info about Spring Interceptor - https://www.baeldung.com/spring-mvc-handlerinterceptor
Do you think this is ideal or do you have any better suggestions for this type of case?
Related
I am writing a Spring Boot service and wanted to include some form of RequestContext available to the controllers that might store things like the authenticated user and a request id. However, I see multiple approaches:
Use an #RequestScope bean
Use ServletRequest.setAttribute
Use Spring RequestContextHolder
What are the tradeoffs between these approaches?
Broadly speaking, RequestScope is the Spring magic way. It internally uses a RequestContextHolder which in turn depends on ServletRequest.setAttribute.
Said differently, the Spring way, is IMHO RequestScope. RequestContextHolder makes sense if you prefer limit the magic of Spring annotations.
Finaly, ServletRequest.setAttribute is still lower level, and should mainly be used if you want the code to be compatible with a non Spring application.
Moreover, for the first two ways, Spring uses a thread scoped object to store a reference to the request context, which allows the programmer to access the beans even in methods that do not explicitely receive the Request object.
I am keeping looking for an authencitation solution in java until I found AOP.
It seesm that the advise of the AOP can act as an interceptor of the required method executation. Which can be use or authentication and authorization.
And I have heard some solutions based on URL filtering, but IMO, the AOP is better since it will intercepte the logic rather then the request path.
Especially in an application which have multiple views like this:,
we can use only one authentication module to hold the whole application through AOP, but if we use the URL filtering, we have to make another authentication module for the "Client GUI View".
This is my opinion, I am not sure if this is right, please figure it out if I miss something.
And BTW, is there a live exmaple about AOP with authentication(Spring AOP is better)?
I don't think using AOP for authentication is a good idea.
You can use filters to check if an user is authenticated. Here you have an example of this:
How to redirect to Login page when Session is expired in Java web application?
Another approach, you can make use of Spring Security. It is quite simple and handle login for you. This guy shows well simple examples:
http://www.mkyong.com/spring-security/spring-security-form-login-example/
My questions is similar to this SO question.
But I am using Spring security 3.1.4 in which following call is deprecated.
(OpenIDAuthenticationToken)exception.getAuthentication()
What is the alternative mechanism to get OpenIDAuthenticationToken in SimpleUrlAuthenticationFailureHandler implementation?
Thanks for your time and help.
If your requirement is to register users who are not already in your system, you can do that in the same way that the sample application does.
If you need more interaction with the user at that point, then the only alternative to the deprecated method that springs to mind would be to use your own custom exception.
I wanted to know whether it is possible to have custom handler execution just before spring authentication manager. I wanted to validate licenses for the user before he access system. Initially i wrote custom filter and executed it before calling to authentication manager, but in this case he wont be able to access some resources since he is not authenticated, but later i moved my code to sucessHandler of spring which worked fine, except it has some security issues like if open in multiple tabs it fails.
Any help is highly appreciated.
Thanks,
Brijesh
I think what you are looking for is to add a Spring AuthenticationProvider. In short, an AuthenticationManager has a list of AuthenticationProviders, each of which is queried in order. The question and answer to Multiple Authentication Providers in Spring Security has a good explanation of this. The Spring documentation also explains how the various components fit together.
What I am looking to accomplish is a filter (or similar) that would handle the authentication model for my Spring MVC application. My application is also hosted on Google App Engine.
The authentication on this application can tend to be very dynamic and the permissions are not something that would fit cleanly into a predefined Role structure. These permissions would be tied to the different action methods on my controllers. Ideally I would like to be able to annotate these permissions but I am open for other suggestions.
I am finding that there is not very much information around on how to accomplish this. Ideally I would like to be able to intercept the call to my controller actions and be able to read off the annotations and handle accordingly. What I am hoping is that someone here has a little bit more knowledge on Spring MVC and where I can inject some custom code, and would be able to point me in the right direction.
I would still use Spring Security to do this. It may not have a class that 100% fits your login scheme, but that's what inheritance is for. Write your own. You can easily get rid of the ROLE based DecisionManager and make it fit your paradigm.
Based on your comments have you checked out the MethodInterceptor in Spring? It creates a Proxy that will intercept calls to any method on the proxied class and allow you to run or disallow the method based on any code you want. In Spring Security there is an AbstractSecurityInterceptor, but I find it very hard to use and for most access decisions I think it's overkill.
So I would use Spring Security to authenticate the user (and populate the SecurityContext) and then use interceptors to wall off access to methods in your controllers that you want protected.