Portal Security Scopes & Access Filters
- 12 Sep 2024
- 5 minute read
- Print
- DarkLight
- PDF
Portal Security Scopes & Access Filters
- Updated 12 Sep 2024
- 5 minute read
- Print
- DarkLight
- PDF
Article summary
Did you find this summary helpful?
Thank you for your feedback
Slate Portals have several options for authentication, depending on the intended End-User audience for the portal. Security Scopes determine what type of records can log in to any given portal. Additional restrictions can be placed on portals via Access Filters to allow only certain records to access them.
Security Scopes
Anonymous / Guest
Portals that are public facing and do not require login or any form of authentication will use the 'Anonymous/Guest' security setting. This form of authentication is the least secure, as no credentials are required, and should only be used for portals that will never display any kind of personal or sensitive data.
Person
Person portals are less frequently used, as they can create a barrier to entry for prospects and inquiries, requiring them to create a username and password to access information in the portal.
If your institution collects Applications in Slate, the username and password that end-users create to access their application and application status page can also be used to access forms and portals with Person-scoped security.
For more information about usernames and passwords for Person records, see Account PIN and Password Reset for Person Records.
Application
Portals that use 'Application' security, such as the Applicant Status Portal, typically use the same authentication that the applicant used when creating their account and starting their application. Applicants create an account, receive a username (their email address) and pin (a randomly generated number, populated on the person's account with an application is created in the active period) via a System Email, and then create their own password upon first login.
Imported Application
Institutions using an imported application, like the Common Application, will have a custom Deliver email that will send out the applicant's username and pin.
Manually Generating a PIN
Pins can also be generated via Upload Dataset and Batch Management after running a query using the same method as Person records.
SSO Authentication
Additionally, SSO can be used to authenticate applicants using an institution's SSO. For more information, please refer to this article on Using SSO for Applicants.
User
User security portals will only be accessible to Slate users and will leverage the institution's SSO for authentication.
Important!
Permissions in Slate are not observed within the Portal. For example, if in Slate, a user cannot access applicants but they have access to a custom portal where applicants are displayed, they will be able to view the applicants. Restrictions for portals will need to be built in using filters on the portal itself or within the portal queries.
Dataset
Dataset portals can use either Slate authentication with a username and pin or an institution's SSO. Institutions may also choose to 'Enable access via secure link' without requiring login.
Secure Link
Enabling the 'Secure Link' setting allows dataset records to click on a personalized link containing their GUID to access the portal. No username and password are required. The link is constructed as follows:
https://apply.slateuniversity.edu/portal/key_of_portal?key=GUID_of_dataset_recordThis link can be emailed to dataset records.
For security purposes, if information displayed on the portal could be personally identifying or otherwise sensitive, we recommend against enabling the 'Secure Link' setting.
Slate Authentication
To use Slate authentication, dataset records will need to have a username set to their email address via a rule. Typically, this will be a Rule Formula in the Rules Editor.
Configure the Rule
Select Database, then select Rules.
Click New Rule.
Set Base to the appropriate Dataset base.
Set Type to Username. Click Save.
Set Action to Replace Values from Formula.
Add in the Export Email.
In the Formula box, enter "@email". This will pull the email value from record: email and establish it as the record: username, which is required for Slate authentication.
Important!
When using Slate authentication for dataset portals, the username must be an email address to ensure delivery of reset password emails.
Once a username is set for a dataset row record, a pin will be automatically generated.
Username and pin can then be used in a custom Deliver email to notify dataset records with instructions for accessing the portal. Similar to applicants, dataset records will create their own password upon first login.
Using Slate authentication for dataset portal would look like this, with the 'Use SSO' setting set to 'Inactive'.
Status - Active
Key - alumni_view
Name - Alumni Interviewing Portal (assignment by captains)
Default View - Home Default
Security - Dataset: Alumni Volunteers
Secure Link - Disable via secure link and require login
Use SSO - Inactive
SSO Authentication
Should an institution wish to use their SSO for dataset portals, the username for the dataset records must be set to their SSO username. SSO usernames can be imported via Upload Dataset.
Source | Destination |
|---|---|
Username in SIS | Record - Username |
With SSO, communications regarding portal login will not need to include a pin, as it will not be used in the authentication process.
Using SSO for a dataset portal would look like this, with the 'Use SSO' setting set to 'Active'.
Status - Active
Key - alumni_view
Name - Alumni Interviewing Portal (assignment by captains)
Default View - Home Default
Security - Dataset: Alumni Volunteers
Secure Link - Disable via secure link and require login
Use SSO - Active
Additional Access Restrictions using Access Filters
Access filters can be applied to portals to restrict the records that are allowed to use the portal. Access filters are used in scenarios where only a certain subset of a type of record - person, application, user, or dataset - should gain access to a portal: for example, an Athletics portal to which only users assigned to a role of "Coach" can enter.
To apply access filters to a portal, click "Edit" on the portal's main page, and click the Filter button in the Restrict Access configuration.
Adding Filters
Security - The Security setting of the portal will determine what filters are available for restricting access.
For example, a portal using the "Application" security setting (e.g. applicant status portals) will have access to filters associated with the primary Application query base.Authorization Fail Custom Message - If you wish to display a custom message when access is restricted, you may add one in the Authorization Fail Custom Message section right below Restrict Access.
Access Filter Best Practices
Filter in the Affirmative
Filters added in the Restrict Access configuration should point to the "affirmative," i.e. who should be allowed access, based on attributes that those records have. Although the NOT operator is available, we discourage its usage and it often obfuscates the nature and results of the filter(s).
Redirects
In some scenarios, you may choose to use a portal redirect instead of access filters.
For example, you may have two separate portals for applicants (i.e. a custom status portal) and admitted or enrolling students. Instead of adding access filters on the admitted student portal so that it does not allow in applicants who don't have an admit decision, a redirect could be added so that they could be immediately taken to the relevant portal in the same browser window. That is, instead of stopping students in their tracks, they can be seamlessly directed to the correct page instead, which creates a friendlier user experience.
Was this article helpful?
