Slate Authentication Service

Slate can act as an identity provider for integration with externally-hosted admitted student websites or other resources that you want to protect behind a Slate authentication page.

Important

To use Slate as an identity provider, an application must exist on a person's record.
Central Authentication Service (CAS)

Slate provides a drop-in replacement for any Central Authentication Service (CAS) 2.0 and greater authentication provider, so the procedures involved to integrate with Slate CAS are straightforward. In the example conversation below, replace slate.uni.edu with the endpoint of your Slate instance. By default, the Slate CAS server will allow authentication from any service in the parent domain of the Slate subdomain. For example, if a Slate instance resides at slate.uni.edu and you want to use Slate to authenticate a user for portal.uni.edu, the uni.edu parent domain would already be allow listed and no special allow listing is required.

If however, you want to use Slate to authenticate a user for uniportal.org, you will need to specify an Allowed Service Domain List using the Configuration Keys tool under the Database section. When adding an Allowed Service Domain List , separate each domain using a comma.

  Note

Only users with Security Administrator permissions can establish the Allowed Service Domain List.

  1. Redirect user to:
    https://slate.uni.edu/account/cas/login
    ?service=https://uni.edu/myservice

    Pass in the URI of your service into the ‘service’ query string parameter.

  2. Upon authentication, the user will be redirected to:
    https://uni.edu/myservice?ticket=myticket

    The query string will include a ‘ticket’ parameter. This parameter is an opaque one-time-use identifier that may be used to retrieve the user credentials.

  3. Send your service URI and the ticket to:
    https://slate.uni.edu/account/cas/serviceValidate
    ?service=http://uni.edu/myservice
    &ticket=myticket
  4. If it's a valid, unexpired ticket, we'll respond with the following (with a content type of "text/xml"):
    <cas:serviceResponse xmlns:cas="http://www.yale.edu/tp/cas" xmlns:slate="http://technolutions.com/slate">
    <cas:authenticationSuccess>
      <cas:user>john@doe.edu</cas:user>
      <slate:ref>123456789</slate:ref>
    </cas:authenticationSuccess>
    </cas:serviceResponse>

    The username is the application identifier that may be used to look them up in corresponding systems or in authenticated API calls. We can also include other parameters in this response, including SIS IDs.

  5. If the ticket isn't valid, we'll respond with something like the following (with a content type of "text/xml"):
    <cas:serviceResponse xmlns:cas="http://www.yale.edu/tp/cas">
    <cas:authenticationFailure>Invalid service ticket.</cas:authenticationFailure>
    </cas:serviceResponse>
  6. To log the user out, you can redirect them to:
    https://slate.uni.edu/account/cas/logout
REST Authentication

Using REST authentication, the external application captures the username and password directly from the applicant and passes it to Slate for validation. For prospective students and applicants, their username is their email address.  For example, consider the following process flow:

  1. Capture username and password in external application.
  2. Initiate a server-side HTTPS request to:
    https://slate.uni.edu/account/rest/login?user=USER&password=PASS
  3. Read in the result, which will be constructed as an XML document.  (The content-type of the response will be "text/xml".)
    • If authentication is successful, a document like the following will be returned:
      <result>
        <status>SUCCESS</status>
        <id>{unique-identifier}</id>
        <ref>12356789</ref>
        <user>USER</user>
      </result>
    • If the username or password is incorrect, or if there is another authentication error, it will return a response as follows:
      <result>
        <status>ERROR</status>
        <message>{error message}</message>
      </result>
Logout

We recommend that all applications provide a logout capability.  If using the CAS protocol, you will need to redirect the student to the logout page within Slate.  (The link is provided in the CAS section.)  If using the REST protocol, no session is ever initiated within the user's browser within Slate, so no logout needs to happen on the Slate end.  We still recommend that you provide an option to terminate the session within your application.

Was this article helpful?
8 out of 9 found this helpful

Comments

0 comments

Please sign in to leave a comment.