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.

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 allows 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.

However, to use Slate to authenticate a user for uniportal.org, you must specify an Allowed Service Domain List in Database → Configuration Keys. When adding an Allowed Service Domain List, separate each domain with a comma.

📝 Note: Only users with the Security Administrator permission can manage the Allowed Service Domain List.

Example

The default authentication context (/account/cas/) assumes that the user requesting access will be an applicant with an active application. If you will use Slate Authentication as a CAS based Identity Provider for Person records, URLs should be constructed using the person scoped authentication path (/auth/idp/person/cas/).

//Application Scope
https://slate.uni.edu/account/cas/login?service=https://uni.edu/myservice

//Person Scope
https://slate.uni.edu/auth/idp/person/cas/login?service=https://uni.edu/myservice

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

Upon authentication, the user is redirected to:

https://uni.edu/myservice?ticket=myticket

The query string includes a ticket parameter. This parameter is an opaque one-time-use identifier that can be used to retrieve the user credentials.

Send your service URI and the ticket to:

//Application Scope
https://slate.uni.edu/account/cas/serviceValidate?service=https://uni.edu/myservice&ticket=myticket

//Person Scope
https://slate.uni.edu/auth/idp/person/cas/samlValidate?service=https://uni.edu/myservice&ticket=myticket

If it's a valid, unexpired ticket, we'll respond with the following, with a content type of text/xml. Make sure that your service exactly matches the service for the issued ticket. If your ticket was issued for /myservice/cas/login but you validate for the service /myservice/, the service will be considered invalid.

[email protected]
123456789

The username is the application identifier that can 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.

If the ticket is invalid, we respond with something like Invalid service ticket, with a content type of text/xml.

To log the user out, you can redirect them to:

//Application Scope
https://slate.uni.edu/account/cas/logout

//Person Scope
https://slate.uni.edu/auth/idp/person/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:

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.

4. If authentication is successful, a document like the following will be returned:

  SUCCESS
  {unique-identifier}
  12356789
  USER

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

  ERROR
  {error message}

Logout

All applications should provide a logout capability.

If using the CAS protocol, redirect the student to the logout page in Slate. Find the link in the CAS section.

If using the REST protocol, no session is initiated in the user's browser in Slate, so no logout happens on the Slate end. We still recommend that you provide an option to terminate the session within your application.