Can somebody point me a good strategy for security crosscutting concern without AOP for a JSF-Spring-Hibernate web application?
Security context (in user's web session) must be accesible in Business (for rules and authorization) and Data Access Layer (to store user name in BD)
I can use Spring IOC but my boss doesn't allow me to use AOP.
You could use Spring Security's SecurityContextHolder which uses a ThreadLocal to store the current user's credentials. Then you can just access it as necessary from the business layer and the DAOs, at the cost of coupling these to the Spring framework.
You can use Java EE Interceptors but it might be little more difficult to set up than Spring AOP since you are already using Spring stack.
Related
I wanna refactor a monolithic spring boot application basically a web app with login and functionalities for customers. We already have a Security implementation which works with a session id stored as a cookie but I dont have much knowledge about it at all and im completetly new to this topic. It seems JWT is a better solution for Microservices because of an independent authentication service.
So my questions are:
is it alot of work to create a JWT authentication service and exchange the session id implemenation? (since im doing it for my bachelor thesis and have a clear deadline)
can I stay at the session ids while using microservices?
are there maybe other ways to implement authentication?
is it alot of work to create a JWT authentication service and exchange
the session id implemenation? (since im doing it for my bachelor
thesis and have a clear deadline)
This question is hard to answer, as it depends how tightly coupled your particular implementation is. It's certainly not trivial.
can I stay at the session ids while using microservices?
Yes, but you need to figure out how to federate sessions across the microservices (i.e. how to get the information in the session from one service to the other). Overall, this represents a risk of tight coupling between services, so I'd recommend treating this as a transitionary step only.
are there maybe other ways to implement authentication?
As many as the day is long. That being said, without specific reason to do otherwise, I generally prefer to stick to the middle of the road.
Typical user sessions is not recommended in microservices.You should use Stateless architecture and tokens (Tokens stored in database or JWT).
It's better to use Spring Boot OAuth2.
You should implement an Authorization server and Resource servers with Spring Boot.
Authorization server:
Choose the token storage method (JWT,Jdbc,...)
Configure client details
Add a RESTful Api for user info or enable /oauth/check_token api.(Called by Resource servers)
Resource servers:
Set user-info-uri or token-info-uri in Spring boot OAuth2 properties.
Extends ResourceServerConfigurerAdapter class for securing url mappings.
I'm getting started at building REST APIs with Spring annotated controllers.
My question is very simple: how to perform authentication/authorization in a common place rather than the APIs?
Being an expert C# developer I usually create a custom FilterAttribute for my controllers in order to implement any required authentication code.
I'm not going to use #Secured attribute because I work on custom REST authorization based on custom HTTP headers. I have understood that #Secured works with predefined roles, or perhaps I didn't understand its usage well.
Does Spring offer annotations to perform early filtering of Controllers working on the HttpRequest?
There is a filter-based authentication and authorization plugin at the web container level, provided by Spring Security. However, you can also apply security annotations to the controllers. . . Behind the scenes this uses Aspect Oriented programming to modularize the security concern. Take a look at Spring Security and AOP.
Once you understand a little about the AOP side of things you can customize the authorization however you like - role-based, time of day, whatever - this can be driven by custom annotations.
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 would we implement a Session Facade design pattern in the Spring application? Would the role of the Session facade be simply served by the service bean class that would be annotated for the transactions and will have a session scope?
A Spring service (with singleton scope) is like a local stateless session bean, it is an implementation of the Session Facade pattern, only for applications that are not distributed. Spring does make the case that in most cases services don't need to be distributed and that the distributed aspects of Session facade are not as all-pervasive as J2EE made them out to be.
(When you say "session scope" it sounds like you're confusing session as in transactional with session as in HttpSession, because Spring uses the term session scope to refer to HttpSessions. (At least it's confusing me about what's intended.) My reading of the Session facade description leads me to think it doesn't have anything to do with an HttpSession.)
Anyway, I'd say the basic goal of encapsulating complexity is still valid. In some cases the goal of giving distributed access is still very valid, it's just not the default case like J2EE tried to make it out to be. And Seam makes a case for stateful session beans still being relevant.
Session should be associated with the web tier, not services.
Services do indeed own transactions, so they should have that annotation.
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