ESOE Features

Bradley Beddoes

Applicable versions


This page is meant as a guide to new comers to the Enterprise Sign On Engine who would like to get an appreciation for what abilities the ESOE has an what kinds of problems it may be able to solve for your situation. Over time as ESOE is adapted to more installations we'll be adding case studies and other materials.

Currently the ESOE is technology which is used to manage access and data transfer to applications in the web tier. In the future this will be extended to include web services and a host of other resources as developers start trialling more and more far out concepts on the building blocks it now provides. This is a community project, its direction is driven by the needs of our users so if you have a particular feature requirement please join our mailing lists and get a discussion started.

As a quick overview the ESOE can
  • Authenticate users to the web tier
    • LDAP
    • Active Directory
    • Anything else you like!
  • Federate with business partners
  • Provides application single sign on (SSO)
  • Support for multifactor authentication
  • Transfer identity data to applications for use in real time
  • Enforce access control policies
  • Enforce registration of services and cancellation of services to your deployment
  • Extend to meet other needs for your company

Each heading below lays out more detail on what the ESOE can do for you.


The first major component that ESOE handles is authentication. It can do this to a variety of backend datastores such as the out of the box provided LDAP compliant directory connector. The architecture is such that any datastore can actually be used with the creation of an authentication module. This might be databases, flat files, web services or basically any other component you might already have.

To show off this flexibility the ESOE also provides a second authentication connector out of the box that talks to Microsoft Active Directory. When windows users interact the ESOE it automatically gets their credentials from the Windows session, validates it against your domain controllers and authenticates the user. We call this "True Single Sign On" as the user only ever presents their password to the operating system itself when they start their session.

The authentication process itself can be customized as needed by a particular implementation. For example you may wish to show users who authenticate for the first time a web page detailing some important messages your company wants them to read and agree to before they are given access to your resources, or you may wish to set a particular cookie, all of this can be achieved using the ESOE.

Finally the interface users see to authenticate and interact with the ESOE is completely customizable to your site. So long as you provide some basic HTML form components you can choose to present your portal any way and anywhere you choose.

Federated Authentication

One of the biggest challenges we face today is remembering all our identities. Usernames and passwords at multiple sites, hard to remember, hard to obtain in the first place a real nightmare. Certainly a big negative when it comes to collaborating with business partners.

ESOE takes care of this problem allowing you to use federated identities. Essentially this means that your business partner can login at their own company, using their local username and password and then access your content across the internet without needing to login again.

We currently support this using two primary technologies, the first being the internet2 shibboleth project and the second being a new technology called OpenID. The former is more heavily used in educational organizations where security and anonymity are highly important. The latter is extremely easy to deploy and is used in sites where security is sometimes less of a concern but you want to be able to gather some basic details about the person who is visiting you.

In the future we'll support even more identity sources including Yahoo BBAuth to truly integrate your company with the rest of the world.

Application Single Sign On

Single sign on has a lot of different meanings, earlier we discussed True Single Sign On to describe the user only needing to authenticate once to the operating system, this is different from Application Single Sign On (ASSO) (and is what most people mean when the refer to SSO).

Once the user has authenticated to the ESOE using one of the methods mentioned previously they never have to authenticate again while their browser is open and their session is active, regardless of how many various applications they visit. For example once I authenticate to ESOE of a morning I can visit our central portal, our blackboard deployment and our confluence deployment all without ever being asked for my credentials again. This is what we mean when we talk about Application Single Sign On. Multiple independent applications all being authenticated to without needing to issue my credentials again.

The best part of all of this is that even though as a user I have no knowledge of what is going on underneath the system is doing a lot of work with cryptography and XML to ensure that the sessions are completely secured. Easy to use, works in any web browser, exactly the way I as a user want it to be.

Multi-factor authentication

One of the biggest risks associated with ASSO is that once a potential attacker has penetrated your security, they have access to many resources in your environment. To help mitigate this risk, resources with different levels of trust should be separated. ESOE addresses this problem via multi-factor authentication.

With the addition of modules to the Authentication system you can require that users to particular services must be first authenticated to a certain level, for example your financial system. Users can happily move between all services your company offers with a username and password however when they access your finance system ESOE will require them to authenticate to a higher level before granting access. This may be with a one time token issued over SMS, a 6 digit token pad given to trusted persons or some other kind of technology you wish to make use of.

The real beauty of the solution is that you can have as many levels of security as necessary for your company, with each level requiring even stricter methods of authentication to progress. Of course you don't need to write this support into every application you wish to enforce the levels on either, even when they change. Its all done by the ESOE.

Transfer identity data

Part of ASSO is transfer of identity data from the ESOE to the application regarding the person or other entity that is authenticating.

ESOE is able to connect to as many sources of identity data as you have available, retrieve that data, clean it, combine it and present as single unified source to the end application. This is kind of hard to explain so an example will assist.

At company X we have two LDAP servers, one stores information on personal data such as names, email address etc. The other has corporate data such as membership of different roles. Ideally these two directories should be merged to a single one but practically this can't happen just yet. To be able to make use of this data effectively applications would need to query both sources. If for some reason we add a third source to the mix lets say a database which also has role membership information the ESOE can use this as well. To make things even worse roles in LDAP are identified by "Roles" whereas roles in the database are identified by "client_membership". ESOE can query all these sources and add them altogether in a single view of the person or entity, it can even clean up the various identifiers of the attributes so instead of "Roles" and "client_membership" it presents the application with the simplified identifier of "role" which contains all the data from both sources. Applications never need to know just where the data is coming from and you can change and migrate your backend infrastructure without risk.

ESOE currently ships with support for LDAP out of the box, additional connectors are planned but are very much deployment specific.

Access control

In the modern IT environment some resources are supposed to be shared with external partners. On the other hand some resources should not be shared externally. Having a system that is able to interpret and securely provide correct access to all these resources without inconvenience to the user is paramount. Other systems don't put as much importance on this aspect as ESOE does.

Furthermore auditors want to be able to go through your policies across all systems and make sure that its been done correctly to company standards. With the common application distributed approach this is a nightmare. Furthermore with this common approach your system administrators need to learn a new style of syntax for each platform and application your trying to support.

ESOE rectifies this with it's centralized access control decision making. All policies for all applications in your system are stored and maintained centrally. When a person or entity requests access to the resource the application software will first speak to the ESOE to ensure that the access is allowed. If the ESOE responds in the negative access is denied for that person or entity. When access is allowed naturally the user is granted access. This is combined with some high speed caching and provides for a really solid yet flexible approach to the access control problem.

Centralized registration and management of services

In some large companies various business units can work fairly autonomously meaning that you don't always know who is running a particular application. Furthermore enforcing any control over ensuring things are done securely and that versions of software are patched is harder still.

ESOE deals with these problems on several fronts
  • All services are required to be registered before they can access the system. This includes system contacts (there can be several in different categories), details on the service, the URL users enter to use the service and several other details
  • When the service itself starts up it reports lots of additional information to the ESOE. This detail includes the version of the software the service is using, where it was compiled, the host operating system, IP details and more
  • The above contact detailcan and should be maintained by service administrators. It can then in turn be utilized by ESOE administrators to make contact with the service owners.
  • Services must be activated at the ESOE itself. Should ESOE administrators need to shut down a service for non compliance to some directive this can be done centrally, taking the service offline and denying all access to it


This concludes our overview of features for the ESOE, we welcome your feedback and comments to improve this document and we hope you found it useful in evaluating this product.

Also available in: HTML TXT