Concepts

Relying Party Trust Identifier

When configuring SharePoint for claims-based authentication or authorization, Microsoft SharePoint typically connects to an identity provider such as Okta to retrieve user attributes as claims. To realize all the benefits of claims in an enterprise environment, administrators need to ensure that SharePoint trusts the claims it receives. This means configuring SharePoint to connect to a Trusted Identity Provider such as Okta. Okta retrieves user attributes from Active Directory (or another LDAP directory or data store), wraps them in a SAML token, digitally signs that token, and returns it to the calling application, which is part of a realm. The realm is associated with a web application. It is how Okta maps the sign-in request to the relying party trusts.

Okta People Picker

Okta offers a SharePoint People Picker to find and select native Okta users, groups, and claims when a site, list, or library owner assigns permissions in Microsoft SharePoint. SharePoint integrates with Okta using the Okta API. The Okta API enables administrators to manage permissions for native Okta users and groups in SharePoint. Administrators can define access rules to the SharePoint site and also filter and restrict the results that are displayed when a user searches for a user, group, or claim. These settings are applied to every site within the site collection. For example, administrators can grant access to users who match a certain email address or who are part of an AD or Okta group.

For more information, refer to the following Microsoft docs:

Claims to Windows Token Service (C2WTS)

Enterprise SharePoint deployments can use back-end components that depend on Windows Authentication and require protocol transition from claims-based authentication Okta SSO to Windows Authentication. Okta SharePoint solution enables this protocol transition using Kerberos Constrained Delegation and S4U.

For more information on C2WTS, refer to the following Microsoft docs:

SharePoint People Picker 2.x.00

Okta SharePoint Claim Provider integration uses email or username as the claim value to uniquely identify a user. It allows you to select from two search scopes to query users from: OKTA and APP.

OKTA

If OKTA is selected, People Picker queries for Okta users and creates People Picker entity claim values in SharePoint from their Okta user profiles.

  • If the identifier selected is Email, then the claim type Email will be populated from the Okta user’s profile email.
  • If the identifier selected is UserName, then the claim type Username will be populated from the Okta user’s profile login.
  • When the search scope is OKTA, users can search on firstName, lastName, and email of the user's Okta user profile.

APP

If APP is selected, People Picker queries for app users in specified app instance and creates People Picker entity claim values in SharePoint from their App user profiles.

Info

Note

When UserSearchScope is set to APP, search for groups is not performed at app level.

  • If the identifier selected is Email, then the claim type Email will be populated from App user’s profile email.
  • If the identifier selected is UserName, then the claim type Username will be populated from App user’s profile username. AppUser.UserName field mapping can be used to customize the Username claim type with a unique and immutable identifier.
  • When the search scope is APP, users can search on firstName, lastName, email, and userName of the user's App user profile.

Important to Know

  • When you rename email addresses based on name changes such as marriage or divorce, the identifier becomes not stable or immutable. Since the email address is persisted in SharePoint as the claim value for an authorization rule, it is possible that a different user with the previous email address would get unintended access to the resource.
  • Okta Claim Provider does not restrict which external users can be selected in an Okta org and allows wild-card matches for any prefix match of email, firstName, or lastName profile attributes. It is possible to grant a user access to a resource but the user is not assigned the SharePoint application in Okta. Filtering for Active Directory domains can't be used if the users are sourced from Okta.
  • If you already have a previous version of People Picker installed, completely uninstall it and then install the new People Picker.
  • If you want to change the UniqueUserIdentifierClaimType for the SharePoint farm, first remove Okta Authentication by running the PowerShell command remove­sptrustedtokenissuer, and then reconfigure the Okta trusted token issuer with the new claim type.