We have an existing Jetty Application using Shiro that we are moving to Spring Boot, and were wondering which is more straightforward to integrate with our Spring Application, Apache Shiro or Spring Security? We're looking into implementing OAuth2 soon, and we were recommended Spring Security since we were moving this to Spring Boot. Does anyone have any input they could give us?
As you already have Apache Shiro as your security framework. It would be wise to let it be as is. Shiro easily integrates with spring and works with OAuth2 (https://github.com/zhangkaitao/shiro-example/blob/master/shiro-example-chapter17-client/src/main/java/com/github/zhangkaitao/shiro/chapter18/oauth2/OAuth2Realm.java). In case you swith to spring security you will have to reconsider everything again and a large changeset.
If you have a rather small application with not too many users and roles and don’t need to use any overly advanced features, feel free to use Java EE Security. It provides a solid base just for that. Java EE Security possibilities are quickly exhausted though. For example, you can specify only one authentication mechanism for the whole application. Also, if the application needs to be portable, one should definitely use one of the other two frameworks.
Now if there is need for a largely independent, lightweight and extensible security solution, Apache Shiro is the way to go. The downside, however, is that it might take some time to overcome problems. One might also have to implement some features by themselves. Shiro’s design (interface-driven and POJO-based) facilitates this, however.
At last, if the application is already Spring-based, one might as well stay on the train and use Spring Security, there aren’t any real downsides in this case (beside Spring Security being somewhat harder to implement). This is different for spring-less applications, even more if one never has worked with Spring before. Implementation of advanced features is even harder at first and annotations cannot be used unless Spring itself or AspectJ are included. Also, if there is need for Spring OAuth2, one must use spring-mvc, instead of Jersey or RESTeasy, to create REST resources.
With this, our comparison comes to an end. Again, a small reminder about the relativity of our observation. Experiment with the frameworks by yourself and use the one that suits your needs best.
Related
I've been looking at several frameworks that handle authentication and authorization (Apache Shiro, Spring Security, JAAS, Apache Wicket) and am wondering about the disadvantages of JAAS.
I've been reading that it is more complicated and only provides basic security, but I don't quite understand what that means. Also, I've heard to not use it if the application needs to be ported to another system - why is that?
'It provides only basic security' is nonsense. JAAS is a framework within which you can write whatever you need, so it therefore can provide whatever you want it to provide, from simple authentication to any level of role-based authorization, in association with Container Managed Authentication, which IMHO is the only sane way to manage web-app security.
The JAAS programming model I find a little odd, kind of inside-out, but you can do very powerful things with it: for example I built a webapp that would accept a login via either form, session ticket, expiring auto-login token (e.g. for password reset), or client SSL certificate, and in fact it is ideal for scenarios like this.
It appears both "ignoring()" and "permitAll()" are ways to by-pass Spring Security when requesting a web resource. What are the performance differences seen from using either approach and why is one faster/scalable then the other?
According to the Eugen Paraschiv on his excellent blog regarding these parts of Spring security the conclusion would be that something like:
web.ignoring().antMatchers("/resources/**");
is more efficient than this:
http.authorizeRequests().antMatchers("/resources/**").permitAll();
simply because the filter(s) involved in the spring security mechanism will be bypassed...
I am using spring security in my application for authenticating. I want to fail all logins which happened within a specific time period since session start(e.g 150ms). I can write code to achieve this. I wanted to know if spring security has this functionality built in where I can specify a timeperiod and all login request within that specified time fails.
Thanks,
I think there is no such built-in mechanism in spring for this usecase. Your requirement seems not really a common requirement and therefore could not be expected to find something like this in a general programming framework.
I am in an early stage of a small Spring-based project which utilizes Spring Data Neo4j with an embedded database (but possibly could use a server instance in a later development , too).
My data model and relationships have been designed, Spring Security (with Neo4j), MVC and tiles are set up and also seem to be fully functional.
Now I have the additional requirement to allow login with social networks.
I'm really stuck with trying to integrate Spring Social with my above mentioned setup. Basically I have a rough idea that I need to make use of the cross-store Neo4j component but have no real clue, how I could start with it.
I tried to find something useful for my case (SDN Neo4j + Spring Social Security) on github but was not really successful with that either.
Can anyone provide me an example configuration or even point me to some examples (I obviously didn't find before) ... any help is highly appreciated.
I don't think there is a Spring Social connector yet, but it shouldn't be too hard to write (there is one for Mongo). If nothing else, you can use the https://code.google.com/p/google-api-java-client/ directly form a service, exposing the google oauth callback from a Spring Controller, should work too.
https://code.google.com/p/google-api-java-client/
Neo4j connection repository for Spring social has been implemented here using neo4j-ogm. You can reuse that. https://github.com/maciossek/spring-social-neo4j
I'm currently working on a project running on JBoss AS 7 that requires authentication from a variety of sources. I'm trying to get an understanding of the various components that combine to provide authentication.
I have some assumptions / guesses as to how this all fits together, but I need to make sure that my understanding is correct. So below is what I understand to be the authentication process for JBoss AS7.
You have a security realm that defines how users are authenticated. This realm is then exposed to your application in order to secure some or all of it. In AS7 this is configured in the <subsystem xmlns="urn:jboss:domain:security:1.0"> element.
The realm can be configured to authenticate users against a variety of sources using login-modules, such as a database, LDAP, a local file or something else. Multiple login-modules can be defined, and you can specify some combination of login-modules must "succeed" in order for authentication to occur.
The actual username and passwords are passed in via a mechanism defined in the web.xml file (for servlets), defined in the <login-config> element.
Assuming that the above process is correct (and it may not be):
Does this whole authentication process fall under a specification like JAAS, or is JAAS just a small or optional part of this procedure?
Do all types of <auth-methods>'s (i.e. BASIC, DIGEST and FORM) work with all kinds of login-modules? This page would seem to suggest not, but I haven't seen any clear documentation matching <login-module> options <login-config> options.
The username and password flow from a login-config to a login-module seems straight forward enough, but what happens with systems like OpenID or OAuth where there are intermediary steps (like redirection to external login pages)?
How do projects like Seam 3 Security, Apache Shiro and Spring Security fit into this picture?
JavaEE security specification leaves a lot of space to container implementors so I will focus on JBoss implementation to answer.
JBoss security implementation
JBoss relies on JAAS authentication to implement JavaEE security. That way it takes benefits from a stable API and can use existing LoginModule implementations. Login modules are used to authenticate a subject but also to add roles to Subject. JAAS provides mechanisms for authorization, permission checking and JBoss uses it internally.
JAAS LoginModule does not only supports password-based authentication but also token-based authentication.
Token based authentications
A good example of what can be done in JBoss thanks to JAAS is the HTTP Negotiation support for Kerberos SPNEGO: an additional auth-method named SPNEGO is implemented thanks to a Tomcat Authenticator and token validation uses JavaSE standard Kerberos LoginModule.
By the way, the LoginModule API is not a requirement, it may even be too complex for some protocols. For instance, the implementation to support OpenID with PicketLink only uses Servlet API.
Third party security libraries
These libraries often provide security layers to an application running a JavaEE or pure Java context, even if it does not take benefits from JavaEE specifications for authentication or role-based authorization.
Spring Security provides other abstractions than JavaEE security for applications developers to implement authentication and authorization, mainly thanks to ServletFilter when a web application is concerned. A large panel of choices is available to secure his application: it is possible to mix multiple options like: JAAS usage, JavaEE container security usage or Spring Security specific implementations (the case of OpenID and OAuth). There is no dependency to JavaEE either so it may be use almost in any situation when running on JavaSE. Most architect choose to build application security on Spring Security to have the liberty to switch specific implementations in the future.
Apache Shiro is really similar to Spring Security but it is younger and probably easier to set up.
Seam security does not rely on JavaEE security or JBoss but only on Servlet and JSF APIs. It is obviously the easiest option for JSF/Seam-based web application. Behind the scene, it uses PicketLink implementations.
As a conclusion, the question to use third party libraries in addition or in replacement to JavaEE security depends on architectural choices: application complexity, vendor independence and portability, control on implementations for bug fixes or improvements. In your specific context, having multiple authentication sources requires a flexible solution like Spring Security which supports authentication provider chaining (or Shiro).