Explore Access and Security Controls

Learning Objectives

After completing this unit, you’ll be able to:

Describe how Slack identifies users.
Describe how Slack manages display information.
Describe available provisioning options.
Recommend additional access and security controls based on company needs.

Understand How Slack Identifies Users with SAML

In the previous unit, you learned that Slack requires two SAML attributes from the IdP to configure SSO—NameID and Email. Additionally, setting up SCIM based pre-provisioning requires the IdP to provide a Username.

NameID is a unique, pseudo-random string that should not change for the user over time. The IdP assigns it to distinguish each user account. A valid, unique email address must also be provided.

When a user logs in via SAML-based SSO, several things happen that use the NameID and email address.

The user attempts to log in.
Slack checks the email address, and if there’s a match, redirects to the SSO login page and creates a SAML request.
The user enters their SSO credentials.
The SAML request is sent to the IdP and the IdP authenticates the user, checking its director groups.
The IdP sends a SAML response back to Slack that contains the NameID and email address.
If a Slack account exists with a match on either attribute, the user is logged in. Otherwise, a new Slack account is created and the NameID and email are stored. As a result, it’s important that both attributes do not change at the same time. For example, when changing identity providers, NameIDs would change since they’re IdP-specific, but email addresses must match.

the login process described above, depicted as a diagram

If the username attribute is included in a SAML response, it’s stored in Slack and used as the user’s display name. This is what team members see and use in mentions. Username must be unique to your enterprise grid and can be up to 21 characters long. Typically, this is set to be the same as the email address, and Slack uses the portion before the @ sign (for example, "jdoe" in jdoe@acme.com). Although IdPs may allow setting NameID and username to be the same, that is not recommended. When using SCIM to create user accounts, a username and email address are both required.

Manage Display Information

SAML Profile Syncing
Slack enables you to synchronize profile fields in the IdP’s SAML response. These fields include first name, last name, email, and username.

When profile syncing is enabled along with SCIM provisioning, ensure the username sent in SAML responses matches the username sent by the SCIM connector. If these values do not match, Slack reconciles the difference by overwriting the username originally set by SCIM during provisioning with what is provided in the SAML response during login. Additionally, if the display name was set by SCIM and users are blocked from modifying it, the original display name is also overwritten and set to the same value as the new username.

Restricting Display Changes
Each Slack account has a display name shown when other users use mentions. Your IdP can set the display name field and users can be restricted from modifying it.

Because the email address is used as a unique identifier for each account, Slack recommends restricting users from modifying this field as well. Instead, use your IdP’s SCIM connector to set this field and automatically sync any email changes to Slack.

Note that a SCIM connector will only set the display name if users are restricted from modifying it. The same applies for email addresses.

Provision Slack Accounts

There are two ways user accounts can be automatically provisioned in Slack: Just-in-Time (JIT) provisioning and SCIM provisioning (or pre-provisioning).

JIT Provisioning
With JIT provisioning, a user authenticates to login to Slack (via SSO if applicable) and is automatically provisioned a Slack account if they do not have one.

This helps eliminate the time and effort with onboarding new accounts.

In essence, JIT provisioning:

Uses SAML to automatically create a user’s account on their first login (after the first-ever sign-on attempt by the user).
Works with an org’s IdP to pass user information (a limited number of default profile fields) to Slack in a SAML request.
Is the default behavior when SSO is configured.
Forces users to discover workspaces manually (either by search or direction).

SCIM Provisioning
With SCIM provisioning, an IdP is integrated with Slack and uses SCIM APIs to provision Slack accounts before users attempt to login for the first time. If a user attempts to sign in to Slack before the IdP completes provisioning their Slack account via SCIM, Slack uses JIT provisioning and signs them in.

In essence, SCIM provisioning:

Uses the SCIM API to create users ahead of time, and map custom attributes to their profile.
Requires the use of a connector/helper app alongside a supported identity provider. Your SCIM provisioning setup will vary depending on the identity provider you use. Many have built-in connectors that support live syncing of Active Directory groups to Slack. If you’d like to map attributes manually or build a custom script (that makes calls to our SCIM API), see our SCIM API for details. (You can also get in touch with your organization's contact at Slack to explore how our team can build for you.
Allows you to manage Slack users from your IdP.
Does not mark users as active for billing by default. They will only be marked as active when they log in to a workspace.

Two blocks with colored wires connecting to their corresponding places on each, representing how SCIM maps attributes from the IdP to the Slack profile

It’s best practice to use your identity provider’s SCIM integration with Slack to automatically provision Slack accounts as part of the employee onboarding process. Although this is not required, it provides the following benefits.

On Enterprise Grid, IdP groups can be assigned to workspaces so that users automatically get access to appropriate Slack workspaces and even specific channels, creating a more streamlined Slack onboarding process.
Your identity provider acts as the source of truth for profile fields such as the employee’s name, department, and email address.

Set Up IdP Group Assignments

On Enterprise Grid, you can sync your IdP security groups to Slack as IdP groups. These groups can optionally be connected to workspaces so that group members automatically get access to them and streamline the onboarding process. Additionally, IdP groups can be assigned to workspace channels. These will be default channels for all members of the IdP group, but they can choose to leave these channels at any time.

Additional Security Controls

To mitigate security risks, you can implement protocols such as a session duration policy, enforce mandatory multifactor authentication (MFA), or implement protocols that account for all types of Slack members.

Session Duration Policy
Slack session durations can be configured to adhere to your corporate security policy for session durations, if any. Work with your IT admin to balance security with user experience.

If your IdP has a session duration policy configured, we recommend setting the Slack session duration to match it to ensure that users are forced to reauthenticate with your IdP after the specified duration of time has elapsed. Setting a shorter duration than your IdP means users will be unnecessarily directed to the IdP but then immediately back to Slack. Setting a longer duration than your IdP creates a potential security risk because Slack sessions remain active even after your IdP expects users to reauthenticate.

Multifactor Authentication
For an added layer of security, you can require your members and guests to use multifactor authentication when they sign on to Slack.

Slack relies on the IdP to enforce MFA requirements to authenticate full members. For guests, workspace owners, and org owners, Slack provides native MFA enforcement via text message or an authentication app.

Members and guests receive a verification code sent to their mobile device.
To sign in, they enter their verification code along with their password.
Members and guests need access to enter a verification code sent to their mobile device each time they sign in.

User Group Management
Slack provides Org-level and Workspace-level controls over who can create, disable, and modify user groups. By default, workspace owners and admins manage user groups. You have the ability to allow this for anyone, except guests.

Guest Management
Guest roles let you work with people—like contractors, interns, or clients—that only have limited access to your company's Slack workspace.

Guests only have access to channel(s) they have been invited to and with an optional time limit.
They typically log in to Slack with a username and password, but can optionally be required to authenticate via your SSO identity provider.
Their Slack accounts exist and are managed in your enterprise grid (or workspace for non-grid environments) just like full members. This means your session duration and 2FA settings also apply to these accounts.
Although multichannel guest accounts can be provisioned and deprovisioned via Slack’s SCIM APIs, single-channel guests must be manually managed in the Slack client.

API-based management of multichannel guests requires development of a custom integration. No identity providers have built in this functionality.

Guest and Member Invitation Controls
By default, Slack Workspace Owners and Admins can invite guests, and workspace members can invite other members.

To provide additional visibility and control over membership, a request and approval process can be configured so that your Slack administrators can review each request.

Restricting invites also ensures that administrators set up the IdP to allow the invitee to login via SSO, if needed.

Slack Connect User Management
Unlike guest accounts which are managed in your grid/workspace, the external organization provisions and manages Slack Connect user accounts. These external users authenticate using their own identity provider. The external organization also controls their session durations and any MFA requirements.

When setting up a Slack Connect channel with an external organization, permissions can be specified to control whether the external users can only post messages in that channel, or also be allowed to invite others users, install apps, and more.

Preview the Member Experience

After successfully signing in through your identity provider, members will be asked to review terms of service and find workspaces that are relevant to them. With Enterprise Grid, you can preview the onboarding process from a new member's point of view.

Want to Learn More?

In this module, you learned about how Slack plans and roles affect your identity and access management (IAM) policies, the authentication options available to you, as security controls and best practices.

If you’re ready to take your Slack IAM skills to the next level, check out the Implement identity and access management in Slack badge on the Slack Certified site. Whether you’re building Slack experiences at your company, consulting on Slack implementations, or developing Slack apps, more careers than ever are built on Slack.

The Slack Certified program helps you build the knowledge, skills, and mindsets to be successful in:

Tailoring Slack features and settings for your organization
Building apps and experiences on the Slack Platform
Guiding organizations to use Slack more productively

Once you’re certified, you can show off your credentials to the broader community of professionals building on Slack.

도움말 검색