Slate Authentication Service
  • 17 Nov 2023
  • 2 minute read
  • Dark
  • PDF

Slate Authentication Service

  • Dark
  • PDF

Article Summary

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.


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 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 and you want to use Slate to authenticate a user for, the 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, 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.


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

  1. Redirect user to:

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

  2. Upon authentication, the user will be redirected to:

    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:
  4. If it's a valid, unexpired ticket, we'll respond with the following (with a content type of "text/xml"):

        [email protected]

    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"):

      Invalid service ticket.
  6. To log the user out, you can redirect them to:

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:
  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:

    • If the username or password is incorrect, or if there is another authentication error, it will return a response as follows:

        {error message}


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?