--- title: "Portal Security Scopes & Access Filters" slug: "portal-authentication-methods" updated: 2025-08-13T18:01:38Z published: 2025-08-13T18:01:38Z --- > ## Documentation Index > Fetch the complete documentation index at: https://knowledge.technolutions.net/llms.txt > Use this file to discover all available pages before exploring further. # Portal Security Scopes & Access Filters 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](/v1/docs/account-pin-and-password-reset-person). ### Application Portals that use 'Application' security, such as the [Applicant Status Portal](/v1/docs/custom-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](/v1/docs/system-emails), 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](/v1/docs/application-received-deliver-emails-for-imported-applications) 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](/v1/docs/account-pin-and-password-reset-person). ### 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](/v1/docs/application-and-status-page-authentication-sso-single-sign-on). ### User User security portals will only be accessible to Slate users and will leverage the institution's SSO for authentication. 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 select on a personalized link containing their GUID to access the portal. No username and password are required. The link is constructed as follows: ```plainText https://apply.slateuniversity.edu/portal/key_of_portal?key=GUID_of_dataset_record ``` Where `GUID_of_dataset_record` is the GUID of the dataset record. This 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. 1. Select **Database,** then select **Rules.** 2. Select **New Rule.** 3. Set **Base**to the appropriate Dataset base. 4. Set Type to **Username**. [![Rule_Configuration_1.png](https://cdn.us.document360.io/cd8ea7a6-07f3-4846-a554-627ac016d3e3/Images/Documentation/rule_configuration_1.png)](https://cdn.us.document360.io/cd8ea7a6-07f3-4846-a554-627ac016d3e3/Images/Documentation/rule_configuration_1.png) 5. Select **Save.** 6. Set the rule’s **Action**to **Replace Values from Formula.** 7. Select **Export** 8. Select **Email.** 9. In the **Formula**field, enter `@email`. This pulls the email value from `record: email` and establish it as the `record: username`, which is required for Slate authentication. [![Rule_Configuration_2.png](https://cdn.us.document360.io/cd8ea7a6-07f3-4846-a554-627ac016d3e3/Images/Documentation/rule_configuration_2.png)](https://cdn.us.document360.io/cd8ea7a6-07f3-4846-a554-627ac016d3e3/Images/Documentation/rule_configuration_2.png) > [!CAUTION] > 🔔 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: 1. Go to the portal. 2. Select **Edit**. 3. Next to **Restrict Access**, select **Filter**. 4. Select a filter. The Security setting of the portal determines which filters appear. For example, a portal using the *Application* security setting, like an applicant status portal, will have access to filters associated with the primary Application query base. 5. If you wish to display a custom message when access is restricted, you may add one in the **Authorization Fail Custom Message**section. ![](https://cdn.us.document360.io/cd8ea7a6-07f3-4846-a554-627ac016d3e3/Images/Documentation/Screenshot 2024-09-06 at 2.26.27 PM.png) 6. Select **Save.** ### Access Filter Best Practices #### Filter in the affirmative Filters added in the Restrict Access configuration should point to the affirmative. That is: 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 filters. #### Redirects In some scenarios, you may choose to use a [portal redirect](/v1/docs/portal-redirects) instead of access filters. For example, you may have two separate portals for applicants (as with 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. The individual(s) viewing and interacting with external content, such as a portal or event registration page (in contrast to your Slate users). These could be representative of Person, Application, or Dataset records, or might be anonymous. A **globally-unique identifier**, or one-of-a-kind ID that can be used to identify a record or object in your Slate database.