- 08 Oct 2025
- 4 minute read
- Print
- DarkLight
- PDF
Slate Authentication Service
- Updated 08 Oct 2025
- 4 minute read
- Print
- DarkLight
- PDF
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:
| Accepts credentials and issue single-use access tickets |
| Terminates the session |
| Checks of a service ticket and responds with a CAS response object if the ticket is valid |
| Checks validity of a Service Ticket by a SAML 1.1 request document provided by an Returns a SAML (Secure Access Markup Language) 1.1 response document. |
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:
Capture username and password in external application.
Initiate a server-side HTTPS request to:
https://slate.uni.edu/account/rest/login?user=USER&password=PASS
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 is returned:
SUCCESS {unique-identifier} 12356789 USER
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.