Applicants have two primary methods for accessing their applications and status pages.
- Slate authentication (default) using an email address and password.
- Institutional Single Sign-on using credentials created in the institution's single sign-on system.
This is the default functionality in Slate. Applicant accounts are activated using their email addresses and a 9-digit PIN that is transmitted by email, in addition to the birthdate (optional) for verification purposes, which is not communicated by email. Upon activation, the applicant must set a password of their choosing. A salted hash is stored instead of plaintext passwords. The order of operations:
- Direct the applicant to the apply page by replacing "manage" with "apply" in the URL of your Slate database. For example:
- Slate URL: https://apply.slateuniversity.org/manage
- Authentication URL: https://apply.slateuniversity.edu/apply
- The applicant provides:
- First name
- Last name
- Email address
- Birthdate (optionally)
- A system email, including a 9-digit PIN and the above link, is sent to the applicant's email address (also used as the user name).
- Upon accessing this link, the applicant must provide the PIN and birthdate for verification to create a password. This system email can be customized following the procedure in the System Emails article.
- Upon returning to the application, the applicant uses their email address and password to authenticate. If an applicant has forgotten their password, a system email can be sent with instructions to reset the password. This system email is sent automatically but may be customized following the procedure in the System Emails article.
Institutional Single Sign-On Authentication
If preferred, an institution may choose to create accounts in the single sign-on system to credential access to the Slate application.
Slate has the ability to authenticate against one single sign-on system for both administrative users and applicants. If your institution uses separate systems or a different configuration for students and staff, submit a Service Request to Security/Permissions for additional instructions.
Use the following procedure to import the user name from the single sign-on system and direct applicants to the appropriate URL for authentication:
After importing the usernames, direct the applicants to a specialized link that will instruct Slate to hand off authentication to your single sign-on system:
- Slate URL: https://apply.slateuniversity.edu/manage
- Single Sign-on URL: https://apply.slateuniversity.edu/manage/login?realm=&r=/apply/
Using existing Slate credentials will provide the user access, but this can also create an inconsistent user experience. There are primarily three ways of handling this:
- Friendly URL - Create a "friendly" URL that redirects to the special login page (for instance, https://apply.slateuniversity.edu/enrolled could be redirected on the Slate side to https://apply.slateuniversity.edu/manage/login?realm=&r=/portal/enrolled), which mitigates some of the concern because it's an easier URL to publish. Then again, if the user bookmarks the actual portal, they would be sent to the standard login page upon return to the portal directly.
The link above includes a query string parameter of "r" that directs Slate where to send the applicant after authentication. This can be updated to send the applicant elsewhere, if necessary. For example, if your institution imports applications, you may change the parameter to /apply/status/ to send the applicant directly to the status page rather than the application:
Status Page URL: https://apply.slateuniversity.edu/manage/login?realm=&r=/apply/status/
- Slate Credentials - Keep using Slate credentials until the applicant arrives on campus, which is a clean place and time to begin using new credentials for campus resources and stop accessing Slate.
- SSO - Use SSO from the beginning of the process. All logins then go through the SSO, which can clutter it with records that don't need long-term access, but doing so would keep consistent credentials throughout the student life cycle. This option usually requires agreement from the organization's SSO administrators.
If you have enabled the "Require VPN Access: allowed subnets" configuration key, this will affect all logins, including applicants, using your institutional single sign-on. You may need to remove this key to use single sign-on for applicants effectively.