This article gives an overview of SSO (Single Sign On) principles & best practice.
The article also describes how security administrators can implement/ configure AskiaVista to allow/ enable Single Sign On (SSO) for their users.
- Portal application
The application where the user is currently connected (e.g. Intranet) and from where he would like an access to subsequent application (e.g. AskiaVista)
- SSO service
A service that will generate the SSO key (eg. AskiaVistaSSO)
- Final application
The application to connect to (eg. AskiaVista)
In the AskiaVista database there is a field named AuthenticityToken. This field contains a random GUID string for each user. (The AuthenticityToken can be re-generated at any moment to invalidate previous usage).
In the AskiaCtrl\Askia.config file there is a private key (“EncryptionKey”). This is used to used to encrypt/decrypt data transmitted across the network. The key is shared between the SSO service and the Final application.
In the AskiaCtrl\SSOTrustKeys.config file there are some public keys (one per line) that are indirectly used by the portal application to connect the user. To obtain the final PublicKey, you can use AskiaVistaConfigurator.exe that will salt and encrypt or hash the keys.
How it works
- The Portal application sends the PublicKey and the username (or email) to the SSO service.
- The SSO service decrypts the PublicKey with the PrivateKey. If the decryption fails, we return an error. This means that either the PrivateKey or the PublicKey is invalid.
- The SSO service searches for the specified username (or email) in the database. If it doesn’t find it, an error is returned.
- The SSO service gets the AuthenticityToken associated to the user and generates the following data:
authToken : “the_authenticity_token_of_
expiredAt : Date.Now.AddMinutes(1)
This data (SSOKey) is encrypted with the PrivateKey
- The SSO service URLEncodes the SSOKey and sends it back to the Portal application
- The Portal application redirects the page to the Final application with the parameter “sso=SSOKEY”
- The Final application decrypts the SSOKey. If the decryption fails, it returns an error. This means that the PrivateKey or the SSOKey is invalid
- The Final application extracts the ‘expiredAt’ field from the SSOKey and checks if that key is still valid. If it is not valid, it returns an error. This probably indicates an attempt at hijacking the SSOKey
- The Final application extracts the ‘authToken’ field from the SSOKey and tries to retrieve the user with that AuthenticityToken