SSO Single Sign on

Cirrus Shield will allow the user to add many SSO configurations per organization. For now we will use one SSO configuration per organization.

The user can login using SAML authentication into Cirrus Shield.

Each SSO configuration is a record of the SSO standard object.

SSO Standard Object:

• This standard object will contains the following fields:
  • Name: Name of the SSO configuration
  • Certificate File: the name of the certificate taken from the service provider
    • The SAML certificateis a standard x509 certificate in a Java keystore. It can be created using many different tools. 
  • Assertion Consumer Service URL: The URL at which the SAML assertion should be received. ex: http://www.cirrus-shield.net/acs.aspx
  • SP Issuer/Entity ID: is a URI given by the Service Provider (SP) that uniquely identifies it. It is recommended that the URI is a URL that contains the domain name of the entity. Some identity providers might need this to establish the identity of the service provider requesting the login. ex: saml-CirrusShield
  • IdP Issuer/Entity ID: The URL to which the authentication request should be sent. This would be on the identity provider. ex: https://identity-infovista-sas.cs89.force.com/customers/idp/endpoint/HttpRedirect
  • Organization GUID: The organization ID
  • Single Sign-On Service URL: (provided by IdP) this is the IdP initiated login URL.
  • Single Logout Service URL: (provided by IdP) this is the URL that the user will be redirected to after logout from Cirrus shield.
  • Name ID Format: Defines the name identifier formats supported by the identity provider. Name identifiers are a way for providers to communicate with each other regarding a user.

  • Ex: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

  • Update Existing User’s Attributes: (yes/no)

  • Allow To Create New User: (yes/no)
  • Profile: it’s a picklist that display the available profiles in the organization (if Auto create users is checked, this picklist will be enabled otherwise it’s hidden).

SSO Mapping Field Standard Object:

• This standard object will contains the following fields:
  • Name: the name of the Mapping field
  • Cirrus Shield Field: it’s a picklist that display all the “User” object fields excluding all the fields of type “Password”.
  • Third Party Field: it’s the field name of the external system.
  • Matching field: (yes/no). It can be either the “Username” either a field unique and required and set as External ID. Once the “Username” field is selected, the “Matching Field” is checked.
    • We can have only one matching field.
    • An error message is displayed, if we try to set a second matching field. “Another field is already defined as the matching field for this SSO configuration, please uncheck the “Matching Field” checkbox on the other field before enabling this field as the matching field.”
    • If we try to set a field as matching field and it’s not set as unique, required and External ID, an error message is displayed: “This field cannot be a “Matching Field” because it is not set as External ID, Unique and Required.”
    • If we try to map a field that is already mapped, an error message is displayed: “This field is already mapped.”

SAML AUTHENTICATION FLOW:

Once we have a SAML Assertion Response, we will follow the SAML process as follow:

• If the username in the SAML response is not logged in Cirrus shield, then the system will do the following:
  1. Get the related organization GUID of the user
  2. Get the correspondent SSO configuration (for now, we have only 1 per organization)
  3. If there is no SSO configuration, the user is redirect to Cirrus Shield login page and an error message will be displayed and
     1. Error message: “There is no SSO Configuration in this User’s Organization.”

• Cirrus Shield will check if the response is SAML authenticated
  1. If yes, the user will login into Cirrus shield
  2. The user info will be updated based on the SAML Assertion Response attributes if we have the following conditions:
     1. “Update Existing User’s Attributes” checkbox is checked
     2. There is a field set as matching field (it will be used to find the user and update it)

• We have mapping fields (only the mapping fields will be updated)

1. If the user doesn’t exist in Cirrus shield (based on the “Username”), it will be created if the “Allow To Create New User” checkbox is checked (same as Joomla)
   1. The newly created user will have the profile selected in the SSO configuration.
2. If the user doesn’t exist in Cirrus shield, and the “Allow To Create New User” checkbox is unchecked, the user is redirect to Cirrus Shield login page and an error message is displayed.
   1. Error message: “The LoggedIn User does not exist in Cirrus Shield.”

• If the SAML response is not authenticated, the user is redirect to Cirrus Shield login page and an error message is displayed.
  1. Error message: “SSO is failed! n Certificate is invalid.”

If there is no SAML Assertion Response, then the Cirrus Shield login page is displayed, and the user will follow the normal login steps.