Over the past several years I have spent a lot of time working with enterprise Single Sign On (SSO), I am amazed at how difficult people believe SSO is. Approaches to SSO do vary in complexity, but they don’t have to; at the end of the day you want to allow users / employees of an organization task easier by providing an easier approach to signing into enterprise applications, a solutions needs to be

• Secure
• Easily maintainable
• Reliable
• Low maintenance costs
• Works without training users

and, just simply works. I have seen many different approaches, spoken to many IT individuals and come to the conclusion  that SSO does not need to be complex, it is relatively easy to develop an authentication plugin that’s secure, maintainable, reliable, requires a low maintenance cost and just simply works. I am not a liberty to highlight the organizations that the software I have written is deployed, I can see they are large enterprises and are considered house hold names. I work mainly with an Oracle database (enterprise edition) with a Web front end written in JS, HTML, CSS with AJAX communication and JSON used as the transportation layer. I am not going to provide any code snippets in this article, I will just run through my approach to SSO, this approach can be deployed using any language. It is discussed in terms of an application, of course if SSO needs to be deployed and the underlining applications cant provide these suggestions then you need to deploy a different SSO architecture. However, their is no reason why any application can not deploy such a solution.

I hear a lot about Kerberos Tickets and Native Windows Authentication (NWA); OK if you go down these routes your authentication plugin will be more complex than my suggestions; (yes I have completed projects where Kerberos tickets are used, I found the solution very high maintenance, cumbersome and just too complex),  but I ask all these people who tell me about Kerberos and NWA, why are you making your authentication this complex?

What exactly is single sign on anyway? some say it is using the same username & password combination each time you are challenged to authenticate (i.e. same sign on) others say it is sign in / authenticate once and you never have to authenticate again, both are single sign on. My preference is the idea of same sign on, I think it is more secure, but you cant not forget about organisations that just want users to sign in once and then forget about signing in again, so my approach caters for both. I have seen semi single sign on solutions  using a proxy or where a server in the middle manages usernames and passwords, I have seen large enterprises present these as solutions to other large enterprises, but ultimately it is a enterprise password management solution, I don’t believe this is a good solution, because all this can be is a gloried password management solution, however; sometimes you need to deploy such a solution when the underlining applications don’t have an authentication module that can evolve or can use my suggestion below, if more applications use this suggested solution then these password management solutions would never be needed. Before you look through the suggested solution, remember never store the password anywhere else than the point of truth, the point of truth for vast majority of enterprises will be some LDAP directory. If you want more information on LDAP just go google it, but simple put think of it as a database of objects. An object can be anything e.g. computers, printers, users. And, all we are interested in for authentication is Users. Each organization will have an LDAP in some shape, this maybe Microsoft’s Active Directory, Novell E-Directory, Sun One Directory or even Oracles Internet Directory, each of these are just LDAPs. Also remember you are not trying to take a plain-text password encrypt it or hash it, I prefer to think of it as pinging for the password, hopefully this will make sense when you read the rest of this post.

Lets have a look at an easier solution. Central to my suggestion are two approaches, if you provide both these options you will have a much easier approach to an enterprise Single Sign On solution.

• LDAP authentication
• SSO Passthrough / Trust based solution

Lets start with LDAP authentication; this solution is best termed Same Sign On rather than Single Sign On. Whatever language you are using will have some LDAP library, in my case I have the Oracle Database and all its libraries and therefore have a library called [dbms_ldap] this is a PLSQL wrapper for a Java class; PHP, C# and Java all have LDAP libraries, even Javascript via node.js has an LDAP authentication module. So to summarize this part of the solution, the objective is allow a user enter a username and a password via some UI, these days this tends to be a web UI, once the user enters these credentials you communicate with the LDAP by pinging it using the users full DN (more detail below) and the users password. The LDAP returns with a true or false response, and obviously if it is true the password is correct and you continue and if false the password is wrong. That’s all their is to this solution. As I mentioned above this is best termed Same Sign On, the user uses the same sign on as they do to gain access to their networked computer; this is pretty easy, security wise is this secure, sure it is see more details on how this is secure below.

A bit more detail on this solution; So you enter in your username [darragh.duffy] this will resolve to an attribute in the LDAP, think of an attribute as a column in a database table. But this attribute name can be different depending on the LDAP being used, typically in Microsoft’s Active directory the username is stored in an attribute called [sAMAccountName] or [userPrincinpleName], this is important in order to write an enterprise solution that will work for all your customers you will need to parameter drive this attribute / column but that is easy, simply create your own database table containing this attribute / column, this is the first attribute you will need to store, in the case of Active Directory you will need to store either [sAMAccountName] or [userPrincinpleName], I have seen organisations use an email address as the username, so if users logon as their email address [darragh.duffy@domain.ie] then the attribute for email address will need to be stored in this column. Next you need to search the LDAP directory and find the user [darragh.duffy] so you search the LDAP looking in the [sAMAccountName] attibute for [darragh.duffy] once found you will have a handle to the user [darragh.duffy]; because this is an object you will have access to attributes within the object, and it will contain an attribute called the full distinguished name, in Microsofts active directory this is [distinguishedName], you may want to hold this attribute as a parameter as well, becuase other LDAPs use different attributes. I think Novell call it [entryDN], but who cares as long as you keep it as a parameter, the LDAP administrator will know the attribute name. This distinguished name is unique and will typically look like  [cn=darragh duffy,cn=Users,dc=Company,dc=com] Once you have the DN you can then complete a simple bind to the LDAP; this is very like a ping using the full DN, the LDAP server, the port number and the password, lots of information on the internet to complete a bind to an LDAP. Now; most LDAPs do not like you completing an anonymous bind so your LDAP administrator will need to provide what is called a service account; you use this service account to search the LDAP to find the full DN of the user attempting to login.

Is this solution secure, well of course it is; you run HTTPS for the Web UI to your Web Server; OK so you are at the Web Server now, remember my solution in this case runs from the Database server to the LDAP, so I must secure Web Server to Database Server first, this is possible by securing the communication between web server and database server using TCPS, now I am at the database server so need to go communicate securely from the database server to the LDAP server, again use SSL for LDAPS typically on port 636. Alternatively deploy your solution on the web server and securely communicate with the LDAP server. OK so their is a bit of work in the security side.

This is a low cost, highly reliable solution; I know because I have seen this solution working in organizations with 10K+ users. It works nicely and has relatively zero maintenance. Remember I mentioned you need two components for an enterprise solution, because the solution just discussed will work for the majority but some organizations will request a more “streamlined” solution, one which is typically more like native authentication, this is what I call SSO Pass-through.

Next lets discuss SSO-Passthrough.

This is more like a native windows authentication solution or a trust based solution, it does not require LDAP instead your application creates an authentication API; accepting some key parameters the main parameter being a unique identifier identifying who the user is. You are trusting the other application to have completed the authentication, so somewhere else in the enterprise some LDAP authentication will already have taken place; in the other application a link or shortcut is clicked this launches your application calling your authentication API, accepting among other parameters the unique identifier (any other parameters would be therefore security reasons). This unique  identifier is the key, indicating to your application who the user is, your application does not need any password because you trust the application calling your application, once you have the unique identifier you complete some of your own checking i.e. is this a valid identifier, if so you allow the user to proceed. This is a very easy solution to deploy, however security becomes essential. Firstly the unique identifier most be secure so you need to encrypt it strongly, I suggest using the strongest encryption available to you, in my case I use AES-256 bit key, and I add a type of “salt” called a nonce, yes you could use an IV as well, but I tend to use a random nonce based on the servers system timestamp. Both applications; yours and the trusted application must accept the same terms and use the same private key and nonce, (yes you could enhance and go with a public / private key encryption) but AES-256 is considered by NSA to be secure enough for top secret information and was introduced in 2001 as FIPS-197, so I think it is secure enough. An example of a nonce would be to take the current timestamp from the server in the following format YYYYDDMMHHMMSS e.g. [20120102121130] append this to you unique key which is [123456789] + [20120102121130] which becomes the value to encrypt, and because it is based on a timestamp you can ensure that it is valid only for a period of time, therefore each time you send the unique identifier it is encrypted differently. Some additional security measures you can add include interrogating CGI variables such as the script calling your program, the server it is allowed to run on etc.