Skip to content

Integration: SSO Redirect

Jump to bottom Edit New page
Branden Visser edited this page May 14, 2014 · 1 revision

SSO Redirect Proposal

"SSO Redirect" is a way in which a "Trusted Application" (see proposal for S2S Integration) can redirec ta user to OAE with a token that authenticates them to the system.

The intention of the SSO redirect is to perform an authentication workflow while redirecting to a target resource (i.e., a GET request to a target resource). That is to say, this proposal is not a method in which a trusted application can allow a user to submit a form originating from the remote site such that a POST request is performed on behalf of the user.

The goal of the SSO Redirect strategy is to provide the ability for an external application to redirect a user to OAE in such a way that they become authenticated. To do this, the following workflow is proposed:

  1. Using the same "Trusted Application" creation process described in S2S Integration, a Global Administrator can define a Trusted Application and indicate that the application is allowed to make use of SSO Redirect for its users

  2. The Global Administrator will provide the Trusted Application the private key as described in the S2S Integration workflow

  3. The Trusted Application can redirect a user from their site to a URL that has path /api/auth/signed/sso and contains a signed query string with the following properties:

    • clientId: The public client id for your application
    • email: The e-mail address of the user. This is used to identify the user on the OAE side
    • redirectUrl (optional): The URL path to which to redirect the user after successful authentication. Must be a path for the target domain, may not specify a new domain
    • created: The date (timestamp in millis since the epoch) in which the request was signed
    • duration: The duration (in milliseconds) for which the signature is valid
    • signature: A signature that was signed with all the above attributes, as well as the private application key

(Exact details such as signature hashing algorithm will come closer to implementation)

  1. OAE will validate the authenticity of the request and redirect the user to the specified URL. If no redirectUrl was specified, the user will simply be redirected to their /me page
    • If OAE cannot find the user based on the email address provided, and the item is not a public item, the user will be requested to login. If the user does not have an account, then authentication will not be possible

Assumptions

There are some assumptions being made in this proposed workflow:

  1. The "S2S Integration" has been implemented, giving the external application a public clientId, private key

  2. The users have been preloaded in both systems using respective bulk upload processes, and the email addresses of the upload processes were consistent

    • If users change their email in either system, then the integration will not work for those users
    • If a user has an account in one system and not another due to incomplete bulk upload data, then those users will not have the integration until they either create their account in both systems with their email, or their account is bulk uploaded in both systems
Add a custom footer
Add a custom sidebar
Clone this wiki locally