Designing a centralized service for all user data by implementing authentication and authorization (a&a) mechanism. I’ll share my experience and finalize conclusions for a solution.
The design includes the clients (Web applications) and the server (a&a center).
Authentication is the mechanism whereby systems may securely identify their users. Answering the question “Who is the User?” Authentication also includes SSO (Single sign on). A mechanism which giving the users the ability to sign-on once and get ‘free pass’ to all participating resources without an additional sign’s.
Authorization is the process of verifying if the user has role/permission to access certain resources or sections.
Answering the question: Is user X authorized to access resource/Operation Y?
3. Secured clients:
Usually the a&a mechanism working against secured client frameworks: Spring security, Apache Shiro, Wicket Authentication and so on. I will review these later on that post.
Main subjects to consider:
- Authentication server
- Secured web clients framework
- Authorization responsibilities
Full solution providers:
In my research I came across full solution providers:
- Open AM ( known as OpenSSO) – They claim to be an open source project. But after a little while you find out that it’s indeed an open source but not for a commercial use. You need to pay big amount of $$$ for having their a&a package.
- Crowd – By Atlassian. Seems like a fast, good and very cheap solution. But we still heading into a completely commercial open source solution. This one didn’t fit our needs as well.
- Spring Security: Very popular and widely used. Spring Security demands lots of xml configurations when you want to have more than just a basic setup.
- Apache Shiro: – Great product. Very straight forward configuration and permissions support out of the box.
Additionally if you need to support permissions (and not just roles), Spring security doesn’t support it out of the box.
The problem is that Shiro’s community still considered small and the project is pretty new.
- Authentication server:
I came across CAS (Central Authentication Serivce) - great and completely open source project. CAS provides SSO solutions and supports popular protocols such as SAML, OPENID, Auth.
So if we integrate CAS with an LDAP server (To hold our users’ information) we achieve our authentication model (and having SSO out of the box).
CAS is based on Spring and very easy to extend in case we want to make custom changes. You can download the source code easily and custom it the way you want it.
CAS configuration is pretty easy and well documented.
- Secured clients framework:
I chose Spring Security. Three reasons:
- The web application is a Spring based.
- Popular and the community behind is more than enough.
- Integrates perfectly with CAS.
* I mention that Spring security lack of permissions. But there’s a workaround. Short example can be found here: http://en.tekstenuitleg.net/blog/spring-security-with-roles-and-rights
So far we have Spring Security, Cas, and LDAP (OpenLdap) server.
- Authorization responsibilities:
That one might be tricky depends on your project requirements. You could configure your authorization flow in two ways:
- Centralized authorization:
CAS support attributes. That means you could add additional attributes (roles/permissions) to the returning response (via SAML it’s pretty straightforward).
You could actually choose and configure from which source to pull the additional attributes (Database, Ldap, Active Directory and more).
That’s a very neat and elegant solution – one central which able to deliver on request the authentication and the authorization roles/permissions per user.
- Decentralize authorization:
You could configure Spring Security by extending the UserDetails interface. And then let each application to control the authorization logic after a successful authentication.
* There is an open debate whether each web client application should be responsible for its authorization logic or centralized it (As I described at Point No. 1).
- Centralized authorization:
I suggest to determine the right attitude by your project requirements use cases.
We finished by having a completely a&a open source solution for commercial use.
Vulnerabilities in web applications are now the largest vector of enterprise security attacks.
Stories about exploits that compromise sensitive data frequently mention culprits such as cross-site scripting, SQL injection, and buffer overflow. Vulnerabilities like these fall often outside the traditional expertise of network security managers.