Using same identity to login into multiple services over the Global Network is really handy. From the point of user experience, this arguably would be the best invention in whole area of access control in last ten years or even more. However, I emphasized “user experience”. With ability to open multiple services with one login, security became more fragile. Why? Kinda easy answer – it is much more appealing, breaking into one account to get access to all services at once. And yes, the security mostly is still passwords and shared secrets based. There is MFA indeed, if we speak of unauthorized access. However, MFA is not everywhere yet, and it cannot protect if bad guys get access to shared keys on Service Provider side (what possibly had happened in recent OneLogin security breach).
In this post I am going to describe how asymmetric crypto and PKI can help to solve the problem of stolen identity. First I’ll go through some technical background staff and then towards the end I’ll bring in a new player on the SSO field – x.509 certificate as Identity Proof.
Single Sign On is a technology that defines how to manage access control of multiple, independent systems / services, using single interaction with the user to identify the connecting persona, without further need to bother the User on consequent request to another service. From here forth we’ll be talking about authentication and not authorization, in other words, here we care who the User is and not what he’s allowed to do.
On initial access user provides identifying credential and gets Kerberos Ticket-Granting-Ticket (TGT) in return. The latter allows acquisition of Service Ticket to get an access to particular service requiring authentication.
Generally limited to enterprise LANs or other Kerberos networks.
User uses secure dongle to provide credential when requested by Service Provider. It is plugged in once secure session started and is accessed by supporting services during authentication procedure
Common approaches: Old fashioned: username/password
Modern: x.509 certificate provisioned to the dongle through HSM
Combination of the two
Secure. Cumbersome. Not fancy.
Uses native security features of Windows clients and servers. It is a set of protocols, that are set in priority order in corresponding setting of IIS. Can act as Kerberos based SSO, by acquiring TGT if Kerberos provider is properly configured and available, if Kerberos procedure fails or is unavailable next option is picked, e.g. NTLMSSP (Microsoft binary messaging protocol, utilizing NTLM challenge-response schema).
Security Assertion Markup Language is a form of federated identity based authentication, intended to be used over the internet.
It is a XML based open standard, that defines format of information exchange between Identity (IDP) and Service (SP) Providers. Messages are transferred through User Agent (internet browser), in some cases messages between IDP and SP can be sent directly.
As it sounds, IDP does not have the content User is trying to access, but has means to verify User identity. On the contrary, SP delegates identity verification to the IDP, and the content is presented at the end of SAML identity validation process.
SSO usually comes only as an additional way to login. Username and password are still there and can be used.
SAML SSO implementation requires proper configuration of IDP on SP and SP on IDP side. Initial trust between IDP and SP is created in SP defined proprietary process (like login with valid Username/Password and configuring corresponding settings of SP application). User signs up with same ID on IDP and on SP, and that ID is provided in SAML Response, that is sent from IDP to SP once IDP had validated the user identity in some custom procedure.
Considering that we are talking about authentication over the internet, SAML will be the SSO technology of choice for this post.
To get general understanding on how it works, consider following login flows:
Well, functionally there’s a session ID somewhere, to allow SAML Single Logout. But the latter is not in scope of this discussion, due to the fact, that it is just very similar to login message exchange. Nothing related to initial authentication process that takes place on IDP.
It is easy to spot, that IDP authentication process is absolutely unspecified. What standard defines, is the format of SAML request/response messages and bindings (the way messages are sent: POST, redirect).
Historically, most existing IDPs use same LDAP schema for user identification. This leads to the same security issues as in regular old-fashioned login, where authentication is held by the SP.
What would be really nice – is to make a User identity a crypto challenge. Like SSH. Not any challenge, but one where the secret is known only to the identity owner.
There is a well known way of doing that – RSA asymmetric cryptosystem. It is what is used to create a popular x.509. In several words: there are two keys one is called private and is usually stored in secure vault, the other is public, and is available to anyone. The public used to verify, that for certain data manipulation correct private key was used, or to encrypt a data to be open only by private key holder.
Let’s remind what x.509 is: a digital certificate that ties together some identity and a public key. And the owner of corresponding private key considered the x.509 owner. Or in other words – x.509 proves the identity of certain private key holder, and that identity is written in x.509 structure.
One can create x.509 at leisure, these will be called self signed, and cannot be approved by standard networking SW (browsers, CA APIs etc.), they are usually used in private networks where trust is built based on internal policy, and verification and management handled by private methods.
Publicly trusted x.509s are produced by Certificate Authorities (CA). They build a basis of what is called the PKI, a basement of secure communication over public networks. Recognizable by common networking SW, they allow a User to rely on standard certificate validation means like CRL and OCSP (both provide revocation state of the cert). Using public certificate, allows its validation on any public network.
What should be done to make x.509 serve some other need except for domain identity? Or lets put it this way: how can one use PKI to create verifiable identity for SAML Identity Provider?
It will require: ability to create such identity at scale, connect this identity to some real ID, deliver it to the target device, manage the PKI for the newborn crypto-ID.
Getting Beame.io cryptoID to a mobile device is a matter of seconds. Keys are generated on a device, ID is a meaningless FQDN and corresponding x.509. All ready to be verified by anyone who requests it.
Using the Beame.io cryptoID, User can make the initial password really tough, just keep it somewhere, it won’t be needed often.
Such identity cannot be broken easily – gonna require steal the mobile device, open the system lock and open the app lock all in several attempts.
5 retries given to open the app, after that – it deletes secure container. So User will be required to go and create new cryptoID from the Identity Provider. Nothing happened.
One can say: what if… Yes. But when User finds out, that the phone is stolen, the current cryptoID is easily replaceable by revoking the old x.509 and creating the new one.
And if User looses the email account? Well, until the mobile is around all OK. If both are gone (email and mobile) – just to go back to the Service Provider and recover from there.
And for the happy end: here’s a demo how SSO works with Beame.io, how any SSO Identity Provider should work.