SSO Process

  1. If SAML is enabled and a connection is made to the SAML reserved path or the SSO button is clicked on the WTC login page, EFT will perform a POST binding to the predefined IdP. See Configuring a Site for SAML for configuration of these options.

  2. EFT subsequently communicates its Entity ID and will verify the issuer's Entity ID upon receiving an assertion from the IdP.

  3. The IdP, if configured with EFT’s information (including certificate info) will validate EFT’s request message signature and process the request POSTed by EFT.

  4. The IdP will next authenticate the user directly using whatever mechanism it was configured to use for authentication (cert, user+pass, 2FA, other), or forward the request upstream to another IdP, or rely on a cached session. Whichever the case, the IdP should authenticate a user it trusts and return a response containing an assertion to EFT.

  5. EFT will validate the IdP’s response message signature, if signed, using the IdP’s pre-configured public key. If the response signature is valid it will read the assertion. If not valid, EFT will deny the claim and return an error. IdP response message signatures are optional.

  6. EFT will also validate the assertion signature using the IdP’s pre-configured public key. If the assertion signature is present and valid, EFT will perform a username lookup, otherwise it will return an error. Assertion message signatures are required.

  7. EFT will also decrypt the assertion if encrypted. If decryption using the EFT site’s private key succeeds, EFT will proceed to perform username lookup, or if decryption fails, EFT will deny the claim and return an error. Encryption of assertions within the IdP response is optional.

  8. EFT will then check and validate the following claims made in the assertion:

    1. NotBefore - Claim isn’t valid prior to the time specified (see clock skew).

    2. NotOnOrAfter - Claim is not valid on/after time specified (see clock skew).

    3. OneTimeUse - Don’t cache and reuse claim.

    4. AuthzDecisionStatement - if Deny or Indeterminate as Decision Type then reject claim

    5. StatusCode - Reject if anything other than status:Success

  9. If EFT cannot evaluate, parse, or understand a sub-element or attribute of the Conditions element then the entire assertion is considered invalid. This is to adhere to SAML 2 protocol.

  10. EFT will next look up the user identity in the claim and attempt to match that username to an existing account in EFT (obtained via directory services called to LDAP, ODBC, or Globalscape authentication provider). If EFT finds an exact match then it knows that the user exists in EFT, where to place that user (their home folder), and what permissions to give that user.

  11. If rejected, the user will see an error and be redirected to the logon page (where they can enter their credentials), or if the SAML reserved path was set as the root path (e.g. “/”), then they will be redirected to the logout page (otherwise it would result in an endless loop of authentication attempts). "Failed to find, unambiguously match assertion subject to existing and enabled account."

  12. EFT includes a predefined IdPSP time offset skew of 180,000 milliseconds (3 minutes) for claim validity in either direction, along with an advanced property where the administrator can specify smaller or larger values, capped internally at unsigned INT (0 to 4,294,967,295) ms. This allows for case where IdP and SP's clocks are not in sync and the assertion has a time window that either causes the user not to be able login until some point in the future, or causes their claim to expire prior to being able to login with regard to the service provider.