Skip to main content

How can we help?

Frequently searched: Android devices, cloning, ADC Gallery, Glossary,...

Askiavista (5&6)

Askiavista is the cross tabulation engine that could be installed on stand alone.

In this article

    Single Sign-On (SSO) with AskiaVista

    This article gives an overview of Single Sign-On (SSO) principles & best practice in relation to AskiaVista.

    The article also describes how security administrators can implement / configure AskiaVista to enable SSO for their users.

    Introduction

    The aim of a SSO is to allow a user to only authenticate (sign in) once and still have full access to several different applications.
     
    As user credentials (usernames & passwords) are security-sensitive information, a secure SSO system will not send or share the user's password (or unique ID).
     
    Although the username or email address are less sensitive information, to prevent / minimise the possibility of a security breach, best practice dictates that this information is not passed via the URL (or in any other non-secure way). 
     
    Furthermore, in the method we employ, the SSO key that is used / passed on also expires after a set period of time (one minute), so it is not re-usable if security is breached.
     
    For more information please see . . . more about SSO.

     

    Terminology

    1. Portal application
      The application where the user is currently connected (e.g. Intranet) and from where he/she would like to access a subsequent application (e.g. AskiaVista).
    2. SSO service
      A service that will generate the SSO key (e.g. AskiaVistaSSO).
    3. Final application
      The application to connect to (eg. AskiaVista).
    4. AuthenticityToken
      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.
    5. PrivateKey
      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.
    6. PublicKey
      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 (add random data) and encrypt or hash the keys.

    How it works

    Firstly, be aware that the Portal application needs the PublicKey hard-coded in the HTML page or in the server-side file or database. Please also be aware that the Portal application needs to store the username (or email) of the user.
     
    1. The Portal application sends the PublicKey and the username (or email) to the SSO service.
    2. 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.
    3. The SSO service searches for the specified username (or email) in the database. If it doesn’t find it, an error is returned.
    4. The SSO service gets the AuthenticityToken associated to the user and generates the following data:
      {
      authToken : “the_authenticity_token_of_ the_user”,
      expiredAt   : Date.Now.AddMinutes(1)
      }
      This data (SSOKey) is encrypted with the PrivateKey

    5. The SSO service URLEncodes the SSOKey and sends it back to the Portal application.
    6. The Portal application redirects the page to the Final application with the parameter “sso=SSOKEY”.
    7. The Final application decrypts the SSOKey. If the decryption fails, it returns an error. This means that the PrivateKey or the SSOKey is invalid.
    8. 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. 
    9. The Final application extracts the ‘authToken’ field from the SSOKey and tries to retrieve the user with that AuthenticityToken.
     
    To further increase security, we recommended you salt the PublicKey / PrivateKey with some hard-coded token. For example:
    string privateKey = “MyPrivateKey”;
    string saltPrivateKey = “MySalt” + privateKey + “AdditionalSalt";
    EncryptionAlgo.Encrypt( saltPrivateKey, data);
     
    We also recommend that you use different encryption algorithms to encrypt/hash the PrivateKey and to encrypt the data with the PublicKey. Some examples of popular/widely used encryption algorithms are BlowFish, TwoFish, Rijndael, AES, SHA256.

    Related articles