Relying Party Trust Identiﬁer
When conﬁguring 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 beneﬁts of claims in an enterprise environment, administrators need to ensure that SharePoint trusts the claims it receives. This means conﬁguring 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 oﬀers a SharePoint People Picker to ﬁnd 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 deﬁne access rules to the SharePoint site and also ﬁlter 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:
- People Picker and claims provider planning (SharePoint Server 2010)
- People Picker and claims providers overview (SharePoint 2013 and 2016)
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.
If OKTA is selected, People Picker queries for Okta users and creates People Picker entity claim values in SharePoint from their Okta user proﬁles.
- If the identiﬁer selected is Email, then the claim type Email will be populated from the Okta user’s proﬁle email.
- If the identiﬁer selected is UserName, then the claim type Username will be populated from the Okta user’s proﬁle login.
- When the search scope is OKTA, users can search on ﬁrstName, lastName, and email of the user's Okta user proﬁle.
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.
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 diﬀerent 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 preﬁx match of email, ﬁrstName, or lastName proﬁle 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
UniqueUserIdentiﬁerClaimTypefor the SharePoint farm, ﬁrst remove Okta Authentication by running the PowerShell command
removesptrustedtokenissuer, and then reconﬁgure the Okta trusted token issuer with the new claim type.