Single Authentication Provider
SharePoint can use Classic Mode AuthenticationAuthentication is distinct from authorization, which is the process of giving individuals access to system objects based on their identity. Authentication merely ensures that the individual is who he or she claims to be, but says nothing about the access rights of the individual. Authentication methods and protocols include direct auth, delegated auth, SAML, SWA, WS-Fed, and OpenID Connect. or claims-based authentication. Classic Mode Authentication is traditional Windows authentication such as IWA (NTLM/KerberosKerberos is a computer-network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner.) or basic username/password schemes. Claims-based authentication is new to SharePoint as of SharePoint 2010 and is built on the Windows Identity Foundation (WIF). There are three types of claims-based authentication schemes: Windows claims, form-based, and SAMLAn acronym for Security Assertion Markup Language, SAML is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). The SAML standard addresses issues unique to the single sign-on (SSO) solution, and defines three roles: the end user, the IdP, and the SP. Here's how SAML works through Okta: SP-initiated flow: the end user requests (principally through a browser) a service from the SP. The SP requests and obtains an identity assertion from the IdP (in this case, Okta). On the basis of this assertion, the SP can decide whether or not to authorize or authenticate the service for the end user. IdP-initiated flow: with Okta as the IdP, an end user goes to the Okta browser and clicks on an app, sending a SAMLResponse to the configured SP. A session is established with the SP, and the end user is authenticated. claims.
Mixed Authentication Provider
You can conﬁgure multiple authentication providers with SharePoint (Windows authentication, forms authentication, and trusted Identity providers) using the same URL without having to extend the web application. Both external and internal users would access the web site on https://intranet.company.com for example. By default the user chooses the authentication method when signing in, or the administrator can extend SharePoint to use programmatic methods of guiding the user to the correct authentication method (based on IP address for example). SharePoint shows the single page for mixed authentication mode where the user can pick the provider as shown below.
Multiple Web Applications and Zones
For technical purposes a zone is a logical path through which users gain access to a web application. The URL is a common public face of a zone. The purpose of the zone is to let users into a web application or other SharePoint application. Most people don’t think about the zone. Users envision a URL that directly accesses the web application, but a zone adds an additional layer of abstraction for added conﬁguration possibilities. A web application can have multiple URLs, all of which lead to the same place and use the same zone. This maximizes re-use and security.
People Picker with Active Directory Filtering
Currently, the Okta People Picker shows Active DirectoryActive Directory (AD) is a directory service that Microsoft developed for the Windows domain networks. It is included in most Windows Server operating systems as a set of processes and services. Initially, Active Directory was only in charge of centralized domain management. (AD) imported users twice: as an Okta user, and as an AD domainA domain is an attribute of an Okta organization. Okta uses a fully-qualified domain name, meaning it always includes the top-level domain (.com, .eu, etc.), but does not include the protocol (https). user. Now admins have the ability to see and manage only the original AD users. Admins can also specify that certain domains retain the original behavior.
Enabling this feature requires setting certain $farm object properties in Sharepoint. Refer to Active Directory Filtering for the needed custom property values.
Hiding People Picker
People Picker is conﬁgured at the zone level for a farm by using the
stsadm setproperty operation. By conﬁguring the settings for the control, administrators can ﬁlter and restrict the
results that are displayed when a user searches for a user, group, or claim. Those settings apply to every site in a speciﬁc site collection. For more information about how to conﬁgure People Picker, see Conﬁgure People Picker in SharePoint 2013. (Source: https://docs.microsoft.com/en-us/sharepoint/administration/people-picker-and-claims-providers-overview)
Restricting People Picker to a Certain Group in Active Directory
If a web application is using Windows authentication and the site user directory path is not set, the People Picker control searches all of Active Directory to resolve users' names or ﬁnd users, instead of searching only users in a particular organizational unit (OUAn acronym of Organizational Unit. Organizational units are Active Directory containers into which you can place users, groups, computers, and other organizational units. It is the smallest scope or unit to which you can assign Group Policy settings or delegate administrative authority.). The
Stsadm setsiteuseraccountdirectorypath operation allows you to set the user's directory path to a speciﬁc OU in the same domain. After the directory path is set to a site collection, the People Picker control only searches under that particular OU.
To restrict People Picker to a certain OU in Active Directory, enter the following command:
stsadm o setsiteuseraccountdirectorypath -path <Valid OU name> –url <Web application URL>
Okta Claims Authentication with Multiple SharePoint Applications (SSO)
Administrators conﬁgure a corresponding Okta appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in. for each SharePoint app. The realm establishes the trust relationship between Okta and the SharePoint application. For each SharePoint application, Okta generates a new "realm" that is used to deﬁne a relationship.
To add a new web app to an existing authentication provider such as Okta, enter the following command:
$ap = GetSPTrustedIdentityTokenIssuer "Okta"
$uri = newobject System.Uri($sharepoint_app)
Replace the $sharepoint_app value with the new SharePoint app URI and the $realm attribute with the new realm generated by the Sign-on tab from the corresponding SharePoint app in Okta.