Deployment Scenarios

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 configure 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 configuration 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 configured at the zone level for a farm by using the stsadm setproperty operation. By configuring the settings for the control, administrators can filter 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 specific site collection. For more information about how to configure People Picker, see Configure 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 find 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 specific 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 configure 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 define a relationship.

To add a new web app to an existing authentication provider such as Okta, enter the following command:

$ap = Get­SPTrustedIdentityTokenIssuer "Okta"

$uri = new­object System.Uri($sharepoint_app)

$ap.ProviderRealms.Add($uri, $realm)

$ap.Update()

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.

Top