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.
Related
I recently readed carefully about the spring mvc 3 beans scope, specifically the web ones(session, request and global session) and i have some doubdts:
If i have a controller, why should i annotate him with other scope aside of singleton? I mean, the controllers are supossed to handle the requests and instantiate the view resources of all the app, so why give them a, for instance, session scope? what is the advantage of do that?
Is advisable making the services layer session scoped?
And finally, is there any convention or good practices that dictates where and when is more convenient the use each one of the web scopes? If there is, can somebody provides me the link or information about it? Not necessary convention or good practices, also your experience about it.
Thanks very much.
I mean, the controllers are supossed to handle the requests and
instantiate the view resources of all the app, so why give them a, for
instance, session scope?
In an average web application, you have various objects that exist on a per-session basis. Example can be user profile, or some kind of cabinet, or wallet, etc.
To be able to use those objects in service, every time you should get from session, and pass through the service chain. Instead of doing this, of course it is better to have those available in your service, without a need to pass it explicitly.
Really good example (in practice) you can find here.
An ideal practical example of request scope bean is HttpServletRequest, which should be unique obviously for each request, therefore it is request scoped and created for each request.
From my experience, without any explicit need for a case, you don't need to bother yourself with changing scopes. It is not without reason that default scope is Singleton, it is by purpose - because in most of the applications and basic scenarios you need beans as singleton. However as your main concern was with Session and Request scopes, the above examples are cases which you need often in web application.
Apologies if this has been somehow already answered somewhere - I can't seem to find an appropriate response to my question. Here goes ...
I am currently working on an app accessible via REST. My current teck stack is as follows:
The presentation layer - exposing the functionality in REST
The service layer - taking care of all the business logic, and
The persistence layer - taking care of all DAOs and database-related affairs.
All of this (including Shiro) is autowored using Spring's IoC.
Shiro is currently wired in the presentation layer, making sure all of the calls are protected. The questions I have are: is this the right approach? Does it make sense to apply it to the service layer and, even more so, to the persistence layer?
Many thanks.
The great thing about shiro, is that it can be used at any level. The only thing that really is needed is the idea of a logged in user. In a web framework, this would normally use standard the standard servlet HttpSession to bind it, but that is not necessary.
In our application, we use it at the presentation level to check whether the user has the appropriate rights to view front end pages.
At the business logic level, we call stuff like SecurityUtils.getSubject().isPermitted("somepermissionstring") in custom logic to make sure the user can't call a method when a button is accidentally made visible for that user.
In the frontend code we use the same idea as the business logic.
It works like a charm for us.
So to answer your questions (IMHO):
is this the right approach? -> Yes
Does it make sense to apply it to the service layer -> Yes, if you need very strict security checks!
and, even more so, to the persistence layer? -> Maybe. You have to ask yourself if the security on the service layer might not be could enough, for example if you expose the persistence layer to some code that doesn't go through the service layer. We do not secure the persistence layer as we only access it via our service layer.
I'm coming from the PHP world. The framework I used most is Symfony which is heavily based on ideas from Spring. One if its bundles called JMSSecurityExtraBundle supports a role ROLE_IDDQD that you can activate via configuration. Authenticating with that role would effectively bypass all the security checks — be those Web security constraints or constraints directly on methods of classes in the domain layer.
Since security related tests needed a user with a particular role to be authenticated, I would authenticate a user programmatically creating an authentication object and passing it to the security context. That way I could test security constraints directly on the domain code without involing any UI.
Since a lot of domain methods would be secured, it would prevent me from setting up fixtures for some of the tests because the currently authenticated user wouldn't have enough permissions to do that. This is where I started using ROLE_IDDQD — I created a method that would take a function that could do anything in the domain layer bypassing any security constraints:
$user = $this->iddqd(function () {
return $this->userManager->save($this->aUser());
});
That method would remember the current authentication, reauthenticate with ROLE_IDDQD, execute the function passed in and then restore the remembered authentication.
I'm migrating the app to Spring and looking for a way to do the same with Spring. I couldn't find any mention of ROLE_IDDQD, so I guess that part wasn't based on Spring Security. Are there any other means to replicate this functionality?
Spring security has a concept of Anonymous user with automatically assigned role "ROLE_ANONYMOUS". You can look for more information here
I solved the problem a long time ago. Here's how I did it.
In my architectures, I usually have a repository layer that abstracts away database access and a manager layer above the repository layer that enforces domain logic.
The problem was in my approach to testing. I tried to use managers to set up test data. I now do it directly using repositories and there's no need for hacks like IDDQD roles and such.
So, basically, I use repositories to populate databases with test data, and then I hit managers to test domain logic in them.
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/
In it's simplest form, I want an interceptor that checks session data to see if a user is logged in, and if not redirects them to the login page. Obviously, I wouldn't want this interceptor to be used on say the welcome page or the login page itself.
I've seen a design that uses a listing of every url to one of two interceptors, one doing nothing and the other being the actual interceptor you want implemented, but this design seems very clunky and limits the ease of extensibility of the application. It makes sense to me that there should be an annotation-based way of using interceptors, but this doesn't seem to exist.
My friend has the idea of actually modifying the handler class so that during each request it checks the Controller it is mapping the request to for a new annotation we would create (ex #Interceptor("loginInterceptor") ).
A major point of my thinking is the extensibility, because I'd like to later implement similar interceptors for role-based authentication and/or administration authentication.
Does it sound like my friend's approach would work for this? Or what is a proper way of going about doing this?
Use Spring Security.
Please have a look at these sites, Spring Framework Annotation-based Controller Interceptor Configuration and
Ability to restrict HandlerInterceptors to specific controller paths
Hope it will be useful.
What about a Servlet Filter on all requests that sends the user to the login page if the user object isn't in the session? For the second part you can use security annotations on the controller methods that can check the user's role.