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) Protocol

Slate provides a drop-in replacement for any Central Authentication Service Protocol (CAS) 2.0 and greater authentication provider, so the procedures involved to integrate with Slate CAS are straightforward.

While Slate does not implement the full CAS Protocol, it does support the following CAS endpoints for the purposes of drop-in replacement:

Example CAS Authentication Flow

In the following example flow, replace slate.uni.edu with your Slate instance host.

By default, the Slate CAS drop in replacement allows authentication from any service in the parent domain of the Slate subdomain. For example, if a Slate database 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 another domain, uniportal.org for example, 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.

🔒 The Allowed Service Domain List requires the Security Administrator permission.

Step 1

User attempts to access your service → Refer them to the appropriate /cas/login endpoint

The default authentication context, /account/cas/, assumes the user requesting access is an applicant with an active application.

If you plan to use Slate Authentication as a CAS based Identity Provider for person records, construct URLs with the person scoped authentication path: /auth/idp/person/cas/.

When a user attempts to access your service, they should be referred to the appropriate /cas/login endpoint for your authentication context, and your service should be included in the service URL parameter:

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

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

Step 2

User enters their credentials → User is authenticated and redirected to your service

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.

Step 3

Ticket received → Send a server-side HTTP GET request to validation endpoint from service to validate the session → Receive CAS response object

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

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

🔔 Important!

Your service URI must exactly match the service URI for the issued ticket. If your ticket was issued for /myservice/cas/login, but you validate for the service /myservice/, the service is considered invalid.

If the ticket is valid and has not expired, Slate responds with a CAS Service Response Object and a content type of text/xml. Your service can consume the data in the response object to authenticate the session.

By default, Slate will return the email address of the Slate record as the cas:user attribute. This behavior can be overridden using the Service CAS Use ID configuration key.

Slate can be configured to release additional attributes in the Response Object, including custom field values. These additional attributes are specified using the Service CAS Attributes configuration key.

📖 Configuration Keys

<!-- Example CAS Response -->
<cas:serviceResponse xmlns:cas="http://www.yale.edu/tp/cas"
  xmlns:slate="http://technolutions.com/slate">
  <cas:authenticationSuccess>
    <cas:user>example-user@technolutions.com</cas:user>
    <slate:person>345d2e1b-65de-419c-96ce-e1866d4c57cd</slate:person>
    <slate:round>Regular Decision</slate:round>
    <slate:ref>774482874</slate:ref>
    <cas:attributes>
      <cas:firstname>Example</cas:firstname>
      <cas:lastname>User</cas:lastname>
      <cas:email>example-user@technolutions.com</cas:email>
    </cas:attributes>
  </cas:authenticationSuccess>
</cas:serviceResponse>

If the ticket is invalid, Slate will respond with Invalid service ticket and a content type of text/xml.

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

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

//Person Scope - HTTP GET
https://slate.uni.edu/auth/idp/person/cas/logout

CAS Authentication Flow using /samlValidate

The first two steps in the preceding example flow, in which the user visits the service and the service requests a ticket, are identical to the standard CAS authentication flow.

Once the ticket is received by your service, rather than sending your ticket in a URL parameter of a HTTP GET (as with the serviceValidate endpoint), the samlValidate endpoint expects a server-side HTTP POST.

The body of this POST request should be a SAML 1.1 request document that contains the ticket issued earlier in the CAS handshake, formatted as a SAML 1.1 assertion artifact:

//Application Scope - HTTP POST
https://slate.uni.edu/account/cas/samlValidate

//Person Scope - HTTP POST
https://slate.uni.edu/auth/idp/person/cas/samlValidate

<!-- Example POST Body formatted as SAML 1.1 Request Document  -->
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
    xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP-ENV:Header/>
  <SOAP-ENV:Body>
    <samlp:Request
        xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
        MajorVersion="1"
        MinorVersion="1"
        RequestID="sample_cas_request"
        IssueInstant="2025-09-15T21:00:00Z">
      <samlp:AssertionArtifact>myticket</samlp:AssertionArtifact>
    </samlp:Request>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

If the ticket is valid and hasn’t expired, Slate responds with a SAML response 1.1 artifact, which can be consumed by your service.

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