Blog Posts Case Management Process Management Process Modeling

Open Source Identity: SSOFI

Blog: Collaborative Planning & Social Business

Today’s post is about SSOFI (Single Sign-On Federated Identity) which is an open source project that unloads some of the more challenging issues from the application. Log in once, and then use any number of applications. The server is fast, lightweight, and easy to deploy.

Why do you want an Identity Server?

Every single little application you write has to worry about who the user is that is accessing it. That means a password, but passwords have to be guarded carefully, and stored with the correct encryption. Any web traffic carrying passwords needs to be set up properly with encryption. Beyond the UI to enter the password, you need features to reset passwords, or to set them up the first time, and that means you need to access an email server. All of that, just to allow someone to log in!

An identity server takes all of that out of the application. All of the maintenance and management if passwords is done in one place on one server accessed one encrypted socket connection. The application has a simple JSON REST protocol to determine reliably exactly who the user is. This allows lightweight applications to be written, and users can access them seamlessly. The applications get strong authentication, without need to implement all the troublesome overhead.

Also, when it comes to development, debugging, and testing, applications often need a special environment which is different from the regular one. The identity server is not tied into your network. Each application can specify a different identity server (production, test, development) and the users are authenticated accordingly.

Furthermore in some cases you want allow users to authenticate to an LDAP server, and on other cases to a simple email address id that allows them to reset their own password. The application need not be aware of these differences. It uses a single consistent SLAP protocol to reliably find out who the user is.

Benefits from Centralized Identity

Consider the movement to micro-services, and to lots of small applications deployed. Every single application needs to know who the user is. If every application has a different password would be a huge usability issue. If there is a common database of passwords which each application checks against, then there is also a security issue because each application has access to the password and must handle that correctly.

What the user wants is to log in once, and to have that same identity to work transparently in every application. That is what SSOFI provides. It is quite simple. You really have only one login session, and that is to the SSOFI server. The password is received and handled in the right way with all the appropriate encryptions.

Once logged into the SSOFI server, each application that trusts the server can verify user identity with a simple JSON REST interaction. This happens without bothing the user, and it makes the entire environment appear like you log in once, and you log in to all the application.

All of the special precautions needed for handling passwords can be done at that one SSOFI server. That SSOFI server can be placed on a publicly available cloud server, given a well known domain name, and encrypted with an SSL certificate. Features of password reset and user invitation are included as well when the SSOFI server is configured to send email. None of that need to be duplicated in every application.

What is the Overhead?

The biggest thing is that it is trivial to install. It is a WAR file, and all you do is submit it to a TomCat or JBoss server. It needs a folder to store the files in. For the password recovery and invitation features, you need to configure the host name, port, SMTP user and password. That literally is all you have to do. It takes almost no memory (a few megabytes) and a small amount of disk space (a few K bytes per user).

The SSOFI server and the application need not be on the same network at all. You can use a SSOFI server hosted on a public cloud, even while your applications remain protected in the test environment. All that is necessary is that the client browser, and the application server, both be able to access the address of the SSOFI server. In general you set up one SSOFI server and use it for all applications being run anywhere.

You can run as many of them as you want, for production use or testing use. The application specifies with server it is going to “trust” and it works. There is no fiddling with network domains or complicated routing. The SSOFI server is known by its URL, and all you need to do is change that one URL to make the application run with a different set of users.

How to Get It

The source is found on GitHub:

You get the binaries from this web page:

Here are some points taken from the GitHub site:

Design Goals for SSOFI


I have been using SSOFI for about 10 years. There is a JavaScript library of about 200 lines that implements the SLAP protocol. Every time I install an application for testing, I just point it at the same identity server. If I am already logged in, it immediately picks up that identity and knows who I am. Because the SSOFI server is available from everywhere, it works in the office, at home, on the road, and even in customer sites. No network domain is involved.

I have a production SSOFI server that authenticates to the LDAP directory server.  That way people all log in with their normal passwords.   But when testing a program, I use a SSOFI server that simply allows test users to be setup with a simple password.  The application does not know how the user password is maintained … it does not need to.

It really greatly simplifies writing of new applications.  It makes it easier to set up testing environments and production environments.

Leave a Comment

Get the BPI Web Feed

Using the HTML code below, you can display this Business Process Incubator page content with the current filter and sorting inside your web site for FREE.

Copy/Paste this code in your website html code:

<iframe src="" frameborder="0" scrolling="auto" width="100%" height="700">

Customizing your BPI Web Feed

You can click on the Get the BPI Web Feed link on any of our page to create the best possible feed for your site. Here are a few tips to customize your BPI Web Feed.

Customizing the Content Filter
On any page, you can add filter criteria using the MORE FILTERS interface:

Customizing the Content Filter

Customizing the Content Sorting
Clicking on the sorting options will also change the way your BPI Web Feed will be ordered on your site:

Get the BPI Web Feed

Some integration examples