I was at the Alliance conference in Orlando this past week, and in the course of presenting and listening to multiple institutions in the higher education space, I picked up on a common thread. There is a lot of confusion on how modern access-level security measures such as Single Sign On (SSO) and Multi Factor Authentication (MFA) work, and more importantly, how they can work together to bolster an organization’s application security posture.
So, let’s start with the basics. I’m going to stay at a high level for this post. If there’s interest, I can dive into the technical nerd-stuff in a follow on. And yes, please encourage me, as I love the technical nerd-stuff.
Single Sign On
Single Sign On (SSO) is essentially an authentication mechanism that allows a user to access multiple applications with a single set of login credentials. Typically, these centralized credentials are maintained in an identity store (LDAP, ADFS, or another provider) and are incorporated into a token standard, such as SAML, that allows for the mapping to the user’s credentials stored in each participating application.
SSO provides a measure of security in that 1) a user does not have to remember (or store on post-it notes) the multiple user names and passwords associated with each application, and 2) it provides a single point to disable a compromised account.
Multi Factor Authentication
Multi Factor Authentication (MFA) is a mechanism where more than one form of authentication is required before allowing a user access to an application, or in the case of granular MFA, to designated sensitive processes or data within an application. Text book MFA dictates that there are three forms of authentication: something you know (user name and password, typically), something you have (a phone that can receive app-based or SMS confirmation requests, for example) and something you are (the rapidly evolving arena of biometrics).
MFA requires the use of at least two of these authentication methods before allowing access. It’s the current standard for securing authentication beyond the use of the standard user name and password method that has become much less secure in these days of phishing attacks and other means of stealing credentials.
MFA is becoming really common these days. Think of anytime you try to access your bank account from a new computer or an atypical location (you’re on vacation in China, for example). You will typically be sent a text with a code to your cell phone that you have to input before you’re allowed access. Again, you start with the something you know, but are additionally required to meet the something you have-based challenge.
It’s not perfect and needs to be implemented securely (which is a moving target), but it is a mechanism that helps prevent many of the common breach vectors that have plagued applications that store sensitive data such as SSNs, bank account numbers and other private information.
Both SSO and MFA utilize the concept of a web “session”.
What Is A Web Session?
Let’s start with what web interactions would be without the concept of a session. We would be in a world where every request made by a web browser would have to include whatever authentication credentials might be required to support the request to the site/application. And, even then, every request would be a one-off request-response without the ability to support multi-step transactions. There would be no persistence that we take for granted when we access online shopping sites or key business applications.
A session is commonly defined as a web server-side storage of information that is designed to maintain information throughout a user’s interaction with a web site or web application. The stored information around the ongoing interaction has a key that is passed between the site/application and every HTTP request that the browser makes. Thus, knowledge of what has transpired in the interactions is maintained and updated and allows for a site or application to respond based on what you did before. And it eliminates the need to re-authenticate with every web request.
How Does SSO Work?
SSO typically involves a user logging into a centralized Identity Provider (Okta, ADFS, LDAP, etc).
And as I’m discussing at a high level, I’m going to stop using the word “typically”, as the various Identity Providers for both SSO and MFA can operate differently under the covers.
Once a user logs into an Identity Provider (IdP), a token (a piece of code usually maintained in a browser) is created.
OK – “usually” is the same as “typically”, so I just have to stick to the most common scenarios.
When the user clicks to access an application that is under the SSO umbrella, the token is used to map the IdP login to the application credentials associated with that user. The IdP does not store the application credentials, but does map the central IdP credentials to an individual application account.
In a perfect SSO world, a user would be assigned application accounts that would have credentials (user name and password) that they would never need to use or know. They would be able to seamlessly traverse the applications they need to do their job based solely on the authentication to the IdP.
The token generated by the SSO IdP can have various parameters that dictate the life of the session that has been established. Timeouts can be specified that would dictate logouts from all SSO-based applications based on inactivity or specified durations.
How Does MFA Work?
SSO is fairly straightforward and adheres to stringent standards such as ADFS, Shibboleth and SAML.
MFA is a little more custom and implementations differ widely between providers.
Common approaches include the use of physical security tokens (key fobs, smart cards, etc), soft tokens (device-based apps that receive challenge requests, etc), mobile authentication (SMS, phone calls, etc) and biometric authentication (retina scans, facial recognition, etc).
The underlying commonality between these mechanisms is that, upon a successful response to the MFA challenge, a token is generated that allows access to the requested resource. The life of that token can be dictated via configuration within the MFA provider profile. Like SSO, this setting can be driven by inactivity or a dictated period of time.
How Do SSO And MFA Work Together?
This is where life gets dicey because cooperation between the tokens generated by SSO and MFA is really dictated by the provider capabilities and the associated configurations.
In general – yes, I found an alternative to “typically” and “usually” – the expiration of an SSO token will block access to all SSO enabled applications if users are prevented from directly logging in. Re-logging into the SSO IdP will be required.
The expiration of an MFA token will block access to subsequent requests for the MFA protected resource, but won’t necessarily block access to other parts of the application.
SSO is a fairly established standard, offering both security and productivity benefits. MFA is still evolving and, while implementations vary greatly, the technology is evolving rapidly to provide that additional layer of identity validation that SSO doesn’t support.
Contact us to learn how Appsian can help bolster your application security posture via SSO and MFA access controls.