I am working on a application with a layered architecture:
Presentation - Service - Data Access
Many of the modules at this service layer need access the currently logged in user. Is it a good idea to have these modules directly access the security context to obtain the UserDetails object?
I'm thinking that if in the future modules from the Service layer need to be exposed to other application as a Web Services, getting the Security Context may not work.
You'd need to be more specific, but you generally shouldn't have the whole stack directly accessing authentication information. Instead, if it's an operation where using aspect-oriented method security isn't applicable, pass the user information to service layers as ordinary method parameters. Use appropriate mechanisms (such as #AuthenticationPrincipal) to cleanly supply authentication information to your top-level facade (Web tier or what have you).
Related
I'm working in MVC application. I need to put/pass couple of values in the controller level and retrieve the same in the service or business layer or persistence layer.
Few said we need to defined security context which is accessible in presentation or in any layer.
Please let me know how to define and access it. Is there is a better way then security context?
Thanks.
I'm new to Spring Security, and I can't grasp the basic workflow of it. I read again and again the official documentation but I feel more confused. I can't figure out what are exactly :
authentication manager/provider
authentication object
user detail
user details service
It seems that authentication object is built thanks to user detail but the latter need the former to be built (that's what I understood from the doc).
Does anyone have a simple explanation on how all of these things are used ?
Authentication manager allows multiple authentication providers (eg an in memory db and a normal db?). Authentication provider looks up a user details implementation, via whichever user details service has been specified. The authentication object is then created from that.
User service and user details implementation are completely independent of spring security, you do not need spring security to use them.
[Ref docs]
I need to have web application which actually consist from few separate wars unified into same navigration bar on UI, i need to have all system secured but have authentication only to main web application and after automatic propagation of this security context to sub web applications. I'm using spring security, could someone help me with advice? thanks
This can be achieved by following approach. In Spring, SecurityContext by default is stored in HttpSession. Instead you can configure it to store in some shared repository.
So, configuration should be changed to use your own SecurityContextRepository implementation instead of HttpSessionSecurityContextRepository. Once configured, the security framework will look at the Repository which is available to all your web applications.
The Repository can be either a database or a cached server.
Spring Security stores the login data in the http session. So what I would try is to share the session between the applications.
It seams that this is possible (in Tomcat) by using the Single Sing On attribute.
But be warned, sharing the session between two applications is not without danger. See this Stack Overflow question.
How can we flow user session from one spring application context to another?
Basically I have one spring application representing Web Layer and another spring application representing REST layer. I want when Web Layer access the REST layer the session containing user info to be available from to Web at REST layer for authentication.
Please suggest.
Edit after receiving first ans:
At present we do have Web Layer in place along with security and all the other flows. What we are about to intended is to introduce REST layer. This REST layer is suppose to be called by present Web Layer and by other APIs. We do not want to make any changes for Web Layer, but at the same time need security to be placed at REST Layer that should work for Web Layer too when calling REST services.
Differentiate between SSO and session sharing. If you just want the authentication to carry between application (user only has to log in once), then you want some form of Single-Sign-On (SSO), CAS is one example, but there are numerous.
If, on the other hand, you need to have access to the full session (and everything the application has put in it) across different nodes (or applications), you could look into something like Memcached or Terracotta. Worth noting is that session replication is fairly I/O intensive and for larger sites it often requires a dedicated network interface for the replication.
I would put it to you, however, that if your applications are so tightly coupled that they need to share the same exact session state, then perhaps they should not be separated in the first place? This smells of faulty design and architecture assumptions.
Can spring Acegi security be used for a social networking application where users can set their security preferences to share their data only with their friends?
The common scenario of the Acegi tutorials is where you want to authorize actions per user role, but what about authorizing users to view specific data, say, only their friends'?
Is it possible to use Acegi for that? How?
Short answer: yes.
Note that Acegi is now part of Spring, and is now known as Spring Security.
As to how to it, that's a much more complicated question, and likely has as many right answers as those willing to try. Your final solution will depend on the needs of the app your developing, the environment your in, and the organization you are designing for. I'll assume that you want everyone (or most) to see the basic information, and that the sensitive information only appears on the page if the requester is a friend.
I believe the most basic means of all will involve using the SecurityContext within your servlet/controllers/resources (far too many ways to design a web app to make assumptions here), and page templates (jsf, jsp, etc..., etc..), to get get access to the currently authenticated user, and include only the information that user is allowed to access.
The fundamental elements of Spring Security are
- Security Interceptor
- Authentication Manager
- Access Decision Manager
- Run-As Manager
- After-Invocation Manager
The actual implementation of a security interceptor will depend on what resource is being secured. If you’re securing a URL in a web application, the security interceptor will be implemented as a servlet filter. But if you’re securing a method invocation, aspects will be used to enforce security.
A security interceptor does little more than intercept access to resources to enforce security. It does not actually apply security rules. Instead, it delegates that
responsibility to the various managers.
Through using proper manager(s) you will manage to fulfill your requirements.
Reference: Manning Spring in Action 2nd Edition August 2007