i am going to build a SSO infrastructure which enables one time log on for some sites.
do you have any idea how does it work,.?
i mean the architectural and how all those sites comunicate and ask if an user is authenticated already, is there any special protocol for it,.?
i am familiar with Java and PHP programming, which one is the best suites the SSO implementation,.?
thank you for your response,
Whatever you do, don't attempt to write your own library unless you have a background in strong cryptography, browser exploits, cookies, and session management. (If you did have a background in these subjects, you likely wouldn't be asking this question, so I will try to give you some more useful advice.)
For Java, there are two big security libraries available: Spring Security or Apache Shiro:
Spring Security is extremely mature but hyper-flexible. It almost does too much for simple applications, but if you're already using Spring, it just makes sense to use Spring Security. It's chock full of features and can do some awesome things if you need highly granurlarized security. It has integrations with CAS (An SSO server) and can authenticate against LDAP, JDBC, and many more. Spring Security is 'declarative'; it relies on annotations and runtime AOP to inject authorization checkpoints into your app.
Apache Shiro is much simpler: a servlet filter and a .ini file and you're up and running. It has really simple SSO and remember me features that are much easier to implement than spring security. The API is programmatic, rather than declarative in nature; which I think is simpler, but makes your code tightly coupled to the Shiro library.
Either route will requires you to stick to mainstream Java patterns and good programming practices. Poor programming elsewhere where nullify any security framework.
Related
I'm actually improving the authentication system of an existing app (JAVA+JAX-WS+Hibernate+GWT). I found the OWASP Enterprise Security API Project and I liked it (except for the documentation). My application needs to be scalable and it requires to balance load between multiple web servers. To be able to do this, I'm thinking of using a signed cookie with session information, instead of using the usual server side approach. I've been looking the source code and examples, but all of them take a server-side session approach.
The question is then, ¿is there something within the ESAPI project to implement this signed cookie mechanism to handle sessions? The idea to use this project is not to reinvent the wheel, but I can build everything if necessary.
If there isn't something useful in ESAPI, are there any similar java security projects that you recommend.
Thanks a lot.
I am currently using Oracle ADF (which is an end-to-end Java EE framework) for building my web applications and GlassFish 3.1 as application server.
The latter supports JAAS (declarative inside its admin console). So, I have created a security realm and mapped them with the roles declared in a configuration file and use JAAS to implement the authorization and authentication security features.
Everything fine, until now! This past weeks I have been researching on Java EE security.
What I've found is that JAAS is good enough if you stick with "basic" security. Moreover, it seems that JAAS (as part of the Java Security Framework) was meant just for Java SE (but since Java EE is built on Java SE, some of it’s modules are being reused, such as LoginMethod and Callbacks).
Then, I've found many posts about JASPIC, finding out that it can be implemented only by a programmatic manner (not a problem) and it's not yet fully supported by app servers vendors, and tried to make a comparison between both. Even if JASPIC1.1 release had resolved some issues, like:
The container will however not fully remember the authentication. The
SAM is still called at each request, and the SAM still has to
re-authenticate
(it doesn't sound so good to me).
Then, I've passed on looking for integrating some security framework. The most famous ones seems to be "Spring" and "Shiro". Of course each one of them has it's own characteristics (may be the first is more suitable on a specific situation while the second in another). What's more important to me at the more are:
Authentication
Authorization
Session Management (and possibly, encryption)
But, everywhere I found contradictory conclusions. The result: I'm more confused now then before searching.
I am just a novice in topics like security, and moreover I am a developer (I have stuff to implement), so it's kinda hard to keep up to date with every new release and the progress on security seems to keep going on every day galloping.
I'd like some facts based on personal experience if possible. Every hint or suggestion is appreciated. I want to be sure I'm confident before taking the implementation step.
JASPIC is the one technology that being a part of Java EE integrates really well with it.
The fact that JASPIC authentication modules don't automatically remember a session is an advantage too as it makes them suitable for stateless applications too (think APIs such as JAX-RS). When you authenticate and do want sessions, then just put the result (username + groups) into the session. Then at the start of each "validateRequest" method do a quick check if there's anything in the session and if so give these to the container again. No need to authenticate from scratch and certainly no need to remember any password!
Shiro and Spring Security are very full featured frameworks. You can barely compare that to JASPIC which is very low level and basic. Both Spring and Shiro don't perfectly integrate with Java EE. Spring Security is often said to be more complex than Shiro.
Hope this helps
The Servlet profile of JASPIC requires that the configured (for the app) Server Authentication module(s) (SAM) be called on every request; exactly so that the SAM will be able to manage authentication sessions (should that be desired)
The profile also supports the case, where a SAM is configured to perform authentication, but then wishes to delegate authentication session management to the encompassing container, which is enabled by the used of the registerSession callback property.
Also as noted by Mike Braun, the profile also supports a stateless mode wrt to authentication sessions, and is fully integrated with the container authorization system; such that JASPIC authentication must occur when the target request is covered by an authorization constraint (such as would be defined in web.xml or by use of the ServletSecurity annotation).
The JASPIC defined Callbacks and the container provided Callback handler, allow a portable SAM to set the container caller principal, to consult the container's user registry for password validation and group assignment, etc.
At work we are developing multiple systems that are highly modular and should not have hard dependencies on each other. Now we need these systems to share a common mechanism for authentication and security - or in other words - SSO (Single Sign-On). It is obvious that we will have to make another module that deals with managing authorization, authentication and security - a SSO module. The point is to have it properly integrated with our other systems.
The two approaches I can think of are:
1) Expose a RESTful service(s) from the SSO that allow the authentication and authorization operations to be performed by the the other two systems.
2) Expose a common API for authentication and authorization that will wrap our SSO functionality and have the two systems reference the API and use it directly.
At the moment we are not considering using any third-party solutions in this area, and we have already done some work on the would be SSO module, so we would prefer to stick to a simple solution that would best utilize the existing efforts.
Which approach should we choose and why? What are the significant benefits of each one over the other? Is there a better alternative?
"should I expose it to REST or have it wrapped in an API?"
Go for the best of both worlds.
Expose the authentication & authorization module as a RESTful service to allow the greatest interoperability regardless of the language, framework, or platform chosen for each of the modules. Anything that can communicate over HTTP could use it.
Then develop a library in your language(s) of choice that communicate with your RESTful service; this will make it easier for multiple modules to use a centralized auth mechanism. So you'll have small clients written in ruby, java, etc. depending on the languages you use for your modules.
This sort of code reuse is one of the key tenants of a service-oriented architecture, and is the way to go in my opinion. A few colleagues and I described this in more depth in a recent presentation based on our experiences at BrightTag and other companies.
Many "enterprise" SSO systems like CAS use a very similar approach (though the CAS protocol isn't RESTful). If you want more advanced features, I would definitely give CAS a look.
Which one is the best approach/method to implement security in Java EE?(JPA/JSPs)
I'm working on a personal project so I can learn Java EE and I am a little confused on how to approach the AUTHORIZATION and AUTHENTICATION process on my website.
I have different roles and I don't want certain users to access certain parts of the website. So I've been searching for docs and tutorials and etc, but everything I find dates to more than 3-4 years ago. Is there anything more recent that I should look into?
Here are some of the things I found:
http://www.oracle.com/technetwork/developer-tools/jdev/oc4j-jaas-login-module-083975.html
Any help would be greatly appreciated!!! :)
Spring Security. Although it is branded as Spring, you might find it useful for web applications; do note that you don't need to write a Spring app to use Spring Security.
If you wish to stick to JAAS, I would suggest using one of the container's login modules, just to get started, before you attempt to write your own login module. Be forewarned that you might end up writing one, if the container supplied modules do not meet your requirements. And, there is a good book on JAAS to help you understand it in detail.
Moreover, take a look at Servlet spec 3.0, to see how annotations can be used declare the roles (#DeclareRoles, which came in servlet spec 2.5) in the servlet itself, before defining what roles have access to what HTTP method (using #RolesAllowed). You can also employ annotations like #DenyAll and #PermitAll, to permit or forbid access to all users. #TransportProtected will ensure that the HTTP method is accessed over HTTPS. All one needs to do, is to map these roles in the source code, to actual roles in the JAAS realm; this often done using a container specific descriptor file.
ADDENDUM
Since you are using JSPs and not Facelets or any other technology for the presentation tier, you might be interested in the JSP tags offered by Spring Security. It is much cleaner that maintaining all of the authorization metadata in a humongous web.xml file.
As far as JPAs are concerned, well, the underlying access to them is usually enforced at the servlets or EJBs. Of course, you can build in more programmatic security, based on your needs - using entity listeners would help in this process as you would be able to intercept load, update and persist operations (if you are that particular, but for the most part building security before your business logic is executed usually is sufficient).
And oh, take a look at JBoss Seam (and Seam security), for it is a complete application development framework built on Java EE.
Something more recent than JAAS is the Spring Security framework. It supports JSR-350 (EJB 3) and thus would work fine in Java EE.
I worked on a Java EE application recently with JAAS. It's pretty current, you can check it's home page at Oracle.
It works with roles, authentication, etc.
You can use it in JBoss and Glassfish, probably the rest of the ASs too.
Spring security tutorial https://www.packtpub.com/spring-security-3/book. Highly recommended.
I'm looking for a servlet filter library that helps me secure our web service against unauthorized usage and DDoS.
We have "authorized clients" for our web service, so ideally the filter would help detect clients that aren't authorized or behave improperly, or detect multiple people using the same account. Also we need a way to prevent DoS'ing of our various services since we have an open-account policy -- limiting the number of simultaneous connections for a user, etc.
We've looked at the Tomcat LockOutFilter and such but those are fairly primitive and only prevent against one sort of attack.
Of course there are many application-specific components of the solution, but I was wondering if someone had written up a general solution as a starting point.
Apache Shiro is an interesting security solution (it was called jSecurity before joining Apache.org). I find their source code much easier to understand and tweak for my needs, and also to integrate it.
iTransformers DDOS servlet filter is a good example for a servlet filter able to apply Remotely Triggered Black holing https://www.rfc-editor.org/rfc/rfc5635 which is the only real/good and scalable way to defend yourself from a DDOS attacks.
If you are using Spring then Acegi security is pretty complete.
Here is a series of tutorial articles.
It looks like you might be able to run this without needing Spring everywhere, See here.
Acegi has become Spring Security since this was posted.
Also looks like www.acegisecurity.org has been hacked.