I have read that, session is against the concept of RESTfulness.
Do sessions really violate RESTfulness?
Session Management in microservices
RESTful Authentication
Since Microservices inevitably use REST, does the same apply here as well? If so, then why do we have Spring session? It even lists 'Spring Session allows providing session ids in headers to work with RESTful APIs' as one of its features.
Apart from Scaling as an advantage of micro-services, it also provides you with the flexibility to choose polyglot architecture i.e (using the right programming language, framework, database for the right job).
If you use spring sessions(which off-course provides session replication across nodes), internally it uses Redis/gemfire/hazelcast as a replicated session store, but you will have to stick to one programming language & framework for all your services i.e Java & Spring resp.(You can off course write your own implementation in other languages to read from session store, but its re-inventing the wheels) And this will take away Benefit of Polyglot Architecture.
So typically in microservices architecture, you have a token-service(and it should be able to scale individually) implementation to generate tokens(aka sessionIds) which are used for Authentication & Authorization in each service and you should try to avoid storing the session information. It will also help to avoid "Single point of Failure".
Related
I've created my own JDBC realm (using WildFly 8.2) as described at paragraph 50.3 of the JavaEE 7 tutorial. My understanding is that JDBC realm authentication implies that user credentials are read and checked by the server, the application doesn't even know the coordinates for the auth-reserved DB.
For a "new user sign up", the only thing I can imagine is to implement a classic solution from the inside of my application: accessing auth DB, check if chosen username is already present, insert row in the table... but doesn't this violate the whole paradigm of "container managed authentication", and maybe insert security holes?
Is there some server-implemented mechanism that I ignore?
but doesn't this violates the whole paradigm of "container managed authentication", and maybe insert security holes?
Yes, more or less. The container managed security concept, where the application is totally unaware of the authentication mechanism and the identity store (location where the user data is actually stored) doesn't really take the use case into account where an application has its own user sign up/register functionality.
The idea seems to be more intended for integrating externally obtained applications (e.g. say a Sonar or JIRA instance) into an existing enterprise structure. There the users are created by an admin using a central system like LDAP, or in some situations even an admin UI of the application server.
Unfortunately many of your typical public web applications aren't of this variety. They are standalone apps (don't integrate with existing internal enterprise infrastructure) and they effectively manage their own users.
The classical concept is an ill fit there, and that's why the Java EE Security EG is currently exploring how to best address this.
You basically have three "solutions" in the mean time:
Just define your DB connection details twice, once at the server level, once at the app. It looks like you were indeed already doing this.
Use JASPIC, which is a container provided authentication API which has the option to let the application contain the auth module. It can use the exact same data source and possible JPA entity manager and such that the application is also using.
Do your security using an external security framework, e.g. DeltaSpike Security or Shiro, that's totally implemented in "user space".
From a Java EE perspective, none is really ideal. The first has the duplicate definition and indeed somewhat violates the principle, the second is by itself okay, but JASPIC is a tad low level, and the second is a rich solution but doesn't integrate well with existing Java EE security.
Here is my specific question:
There is a project which contains a lot of pages which uses Spring Framework on Java.
There is some kind of Admin users and department users.
The problem is that an admin user should see all kind of users(all information).
Sometimes an admin might delete some users: This method should be accomplished.
My project leader told me to look at the session properties access and search if there is a framework for that which should work with Spring.
How could I manage that?
Is there a framework for that? If not what is the best way ?
You can by using Acegi security framework, it integrates with Spring framework. To solve your issue, you have to set current user into Http Session (Spring-Acegi has a specified class for this) and read current user whenever needed.
Spring + Acegi has more features like :
Multiple level security by multiple level filters
Concurrent session support, which limits the number of simultaneous logins permitted by a principal.
Support ACL (Access Control List) and Object Domain Security.
Support authentication&Authorization.
and a lot more
It has a lot of useful utilities and structures.
You can see more information at the following links:
http://en.wikipedia.org/wiki/Spring_Security
http://www.tfo-eservices.eu/wb_tutorials/media/SpringAcegiTutorial/HTML/SpringAcegiTutorial-1_1-html.html
To add Spring Security to existing Spring app follow next example:
http://www.mkyong.com/spring-security/spring-security-hello-world-example/
And I recommend you to read their documentation. Spring have really good documentation.
Another example
I want to protect my JSF pages in a Java EE 6 app.
I want to store users and roles in the DB and have privileged users administer them via a web tool. The privileged users would add users to roles and set certain pages to require certain roles for access.
It seems to me that container managed security won't let me do that. Would JAAS be the way forward?
Any suggestions and links to examples would be appreciated.
The short answer is yes. JAAS will allow you manage security against a database use a LoginModule(many container implementations JBoss offer these pre-canned out of the box) and you can check out this article(http://weblogs.java.net/blog/2006/03/07/repost-using-jaas-jsf) or this book(http://www.java.net/external?url=http://purl.oclc.org/NET/jsfbook/) for more specifics how to authenticate Users and determine authorization parameters with JAAS and JSF.
For your second requirement, I can't see any reason why you can then create a separate tool that has access to those tables to modify credential information. Though this seems like a problem that has already been solved by using an LDAP provider with any one of a number of free and open source web interfaces.
Another nifty feature because of the clear separation of concerns is that you can later easily migrate to LDAP or third party services with little effort.
I recommend that you take a look at Spring Security.
Spring Security is a powerful and highly customizable authentication and access-control framework.
Here is an article that explains using Spring Security with JSF.
I am using ActiveMQ to connect a number of application modules written in Java.
I eventually would have a web interface for the application, developed in either Grails, Struts2, or Rails.
My 2 main concerns are:
to have an external security module that is not bound to the Web Framework in use.
to have an independent security db
Any recommendations for this Architecture?
You should place all your components within a secured firewall. Then you wouldn't need to worry about any kind of security for ActiveMQ. If not a firewall, you should have a way to whitelist your components so only you can connect to them.
For the database, I recommend having one user that read data and one user that writes data. Separating this permissions will be a closer step to someone deleting you data.
You need to secure both parts of your application. For the first part go with Amir Raminfar's answer, and insure that your running on secure servers. Also make sure to use what ever security features are built into MQ to allow the components to communicate securely. For Web Security there is no good way I know of to have a framework agnostic security setup. An option for you may be Spring Security You should be able to integrate it with Struts and there is a Grails Plugin This should make it easier to do security in a relatively common way whether you use Struts or Grails but you will probably not be able to easily use Spring Security from Ruby.
Assuming I'm rolling my own session code, what's the right way to generate a unique and secure session id cookie in java.
Should I not be rolling my own but using something that's already been standardized?
I'm using gwt and the google app-engine platform.
How do I make sessions persist across browser/server restarts?
Using Servlet Sessions in GWT
In the remote service implementation class:
String jSessionId=this.getThreadLocalRequest().getSession().getId();
In the client code:
String jSessionId=Cookies.getCookie("JSESSIONID");
Enabling_Sessions
appengine-web.xml
<sessions-enabled>true</sessions-enabled>
No, you shouldn't be rolling your own.
The session ID needs to be cryptographically random (not guessable from known sources). It's difficult to get this right yourself.
Ideally you should be relying on the underlying framework's session management features. Servlets & JSPs, Struts and Spring have this support, which you should use.
In the extremely rare case that you are writing your own framework with no underlying session management features to rely on, you could start with the java.security.SecureRandom class to begin with. Of course, don't reinvent the wheel here, for broken session management is the same as broken authentication.
Update
Given that you are using Google App Engine, you should rely on the session management features provided by the engine. It seems that it is not switched on by default.