Two Factor Authentication And Smartcloud (Part 1)

The next set of posts, the first in over a year, will explore my latest project, attaching two factor authentication to IBM Smartcloud. This is the topic I bored the pants off people at ConnectED with this year, mainly because I am rather proud of doing it and it has a certain XML parsed coolness. So without further ado this is the first post of a multiple series that tells the story of how I added two factor authentication to Smartcloud for less than $20 Alterian dollars a day.

WHY?

A. SmartCloud does not have it.
B. Google / Office 365 etc do have it.
C. Smartcloud is considered less secure because it does not have it and the others do.

Now whether or not C is actually the case is a moot point. When you line up a comparison table of functions available from the enterprise cloud providers. CIOs and CTOs notice that Two Factor Authentication (2FA) is missing in the Smartcloud column and they consider that to be a failing. A failing, sufficiently notable, to discount Smartcloud from consideration as a cloud based solution.

Such was the thinking in my case. Whilst a Hybrid model Smartcloud deployment ticked all the boxes for user functionality: Notes Mail, Calendar, To Do, Contacts, Connections, Files, Sametime, Meetings, Traveler, Connections Mobile and support for the myriad of our own applications. All this was for nothing if Smartcloud was considered less secure because of the absence of 2FA.

The addendum to the 2FA requirement was, as Google et al had 2FA built in as part of the subscription price any solution we provided needed to be without a noticeable increase in cost per user per month.

HOW?

Well that stinger of minimal cost was the Prime Directive as far as our solution was concerned. There are plenty of Identity Providers (idP) out there that will supply you with 2FA facilities however these will cost you money, $2-$10 per user per month. So by definition these solutions however laudable were outside the bounds of consideration.

We had to this ourselves and we had to do it quickly.

Smartcloud allows for Federated Logon, where the sign-in process is passed to a third party IdP and once it has done all that it needs to do to verify the user's identity it passes a SAML token back to Smartcloud (aka the service provider SP) which allows the user to log on.

The Smartcloud servers do not care what the IdP does other than it has to pass a properly formatted SAML token back to the cloud. What we needed was something we could host on-prem that would validate the user and when required process the 2FA.

Smartcloud has several flavours of Federation

• Normal - All users use Smartcloud for Sign-In
• Federated - All users use a third party IdP to Sign-In
• Hybrid - The user can choose to log on from either the third party IdP or Smartcloud
• Partial - The Admins chooses the server the user will use to Sign-In

The best fit for our purposes was Partial as this left the choice of security to the Admin teams and as such we could enforce the security policies in such a way that we could guarantee that they were being followed while still leaving the option to switch a user back to IBM only security validation should the need arise. (eg a catastrophic failure of the on-prem IdP)


So with that taken care of we now had to select an IdP that would allow us to:

1. Validate the user with the first factor (Userid and Password) 
2. Allow us to control the 2FA process using a second factor
3. Send IBM a properly formed SAML token

Validating the User with the first factor

There are four things to consider here.

1. The data source that we will store the data attributes of the users
2. The code that does the Initial Validation
3. The code that does the 2FA
4. The code that creates the SAML Token

The data store can be anything DB2, MsSQL, MySQL, LDAP. However as we shall see in a later post there are user attributes and separate session attributes the complexity of which made me discount LDAP as a data source.
 
The code was a thorny problem, while some platforms allow for user validation and SAML token production they do not provide easy hooks that allow you to interrupt the Sign-In process and insert the 2FA process and rightly so as this would be a security hole.The complexity of this avenue was discounted, although may want to explore it further.

My core competencies are in RPG/DB2, PHP/DB2 and PHP/MySQL and both allow for complex coding and data stores. The deciding factor was the production of the SAML token. There is an excellent open source SAML framework called SimpleSAMLphp This Framework allows you to create an IdP that will do the first factor (Username and Password) validation, allows you to add in your Second Factor Authentication code and produce a correctly formed SAML token which is posted to the Smartcloud all using PHP.

Platform

The platform choice was an internal one, we were already using our System i's for other web purposes and running the IdP on an SSLed port other than 443 while not impossible was going to be awkward because of the format of the URLs the SAML exchange requires. So the platform of choice for us was a LAMP server again because after System i, this is were our core competencies lie.

Conclusion

So we now had a starting point. A LAMP server with SimpleSAMLphp installed storing all the data we need in MySQL tables. Next we moved on to defining the Sign-In Process in detail and that we will explore in the next post.