Enterprise Java

Authentication and Authorization as an open source solution service

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).



1. Authentication:

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.

2. Authorization:

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:

  1. Authentication server
  2. Secured web clients framework
  3. 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.

Secured Clients:

  • 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.
  • Additionally if you need to support permissions (and not just roles), Spring security doesn’t support it out of the box.

  • Apache Shiro: – Great product. Very straight forward configuration and permissions support out of the box.
  • The problem is that Shiro’s community still considered small and the project is pretty new.


  1. 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.

  2. Secured clients framework:

    I chose Spring Security. Three reasons:

    1. The web application is a Spring based.
    2. Popular and the community behind is more than enough.
    3. 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.

  3. Authorization responsibilities:

    That one might be tricky depends on your project requirements. You could configure your authorization flow in two ways:

    1. 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.

    2. 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).

    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.

Idan Fridman

Idan is Software engineer with experience in Server side technologies. Idan is responsible for various infrastructure models in the software industry(Telecommunications, Finance).
Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Newest Most Voted
Inline Feedbacks
View all comments
10 years ago

i have problem in this code /* * To change this template, choose Tools | Templates * and open the template in the editor. */ package streamciphera51; /** * * @author rashed */ package com.myapp.util.security.crypt2; import java.security.MessageDigest; import java.security.NoSuchAlgorithmException; import java.util.ArrayList; import java.util.Arrays; import java.util.BitSet; import java.util.List; import java.util.Random; import java.util.Vector; import renderable; public final class StreamCipherA51 { private final ShiftRegister[] registers; private final List registersList; public StreamCipherA51() { registers = new ShiftRegister[] { new ShiftRegister(19, new int[] { 18, 17, 16, 13 }, 8), new ShiftRegister(22, new int[] { 21, 20 }, 10), new ShiftRegister(23, new int[] { 22,… Read more »

Binu John
Binu John
9 years ago

Very good article, provides some clarity on the various solutions/options in this area.

Machael Robinson
Machael Robinson
8 years ago

Lost my code can you help me get another

Back to top button