SharePoint 2013 Identity and Authentication Smackdown Tom Wisnowski and Steve PeschkaArchitects – Microsoft Services

The Kirk Evans + Israel Vega, Jr

SPC209

• Authentication modes in SharePoint 2013• OAuth• Server to Server Authentication

Agenda

• SharePoint 2013 continues to offer support for both claims and classic authentication modes

• However claims authentication is THE default authentication option now• Classic authentication mode is still there, but can only be managed in

PowerShell – it’s gone from the UI • Support for classic mode is deprecated and will go away in a future

release, so we recommend moving to Claims • There also a new process to migrate accounts from Windows classic to

Windows claims

Authentication Modes

• The MigrateUsers method in SharePoint 2010 is no longer the correct way to migrate accounts – it is now deprecated

• A new cmdlet has been created called Convert-SPWebApplication

• A simple example – you have a Windows classic web application• Run Convert-SPWebApplication -Identity "http://yourWebapp" -To Claims –RetainPermissions

[-Force]• Your FIRST option for migrating from classic to claims is

to do so in SharePoint 2010 before you migrate your content to SharePoint 2013

Authentication Migration

• If you don’t migrate from classic to claims in SharePoint 2010, you have these options to migrate a SharePoint 2010 content DB:• Option 1:• Create a web application in SharePoint 2013 that uses Windows classic authentication• Attach the SharePoint 2010 content database to this SharePoint 2013 web app• Attaching it will upgrade it to the SharePoint 2013 database format, so verify that it is working

correctly after attach• Run the Convert-SPWebApplication command on the SharePoint 2013 web app to convert the

users from Windows classic to Windows claims• Detach the content database from the SharePoint 2013 Windows classic web app• Attach the content database to it’s final SharePoint 2013 Windows claims web app

• Option 2:• Attach the content DB to an existing Windows claims web application• Use PowerShell to convert to claims a targeted number of databases (explained next)

Other Claims Migration Scenarios

• Both of the migration options on the previous slide do migration at the web application level

• SharePoint 2013 also allows you to migrate only a single content database• Very useful during upgrade, since most content will be moved with DB attach

• A new method has been added to the SPWebApplication class for this purpose - MigrateUsersToClaims

Claims Migration for Content Databases

$wa = Get-SPWebApplication http://yourWebAppUrl $arguments = New-Object Microsoft.SharePoint.Administration.SPWebApplication+SPMigrateUserParameters$arguments.AddDatabaseToMigrate($wa.ContentDatabases[contentDbNumberYouWantToMigrate]) $wa.MigrateUsersToClaims("domain\user", $true, $arguments)

Claims UpgradeTom Wisnowski

• One of the big improvements is that SharePoint tracks FedAuth cookies in the new Distributed Cache Service• In SharePoint 2010 each WFE had its own copy• That meant that if you got redirected to a different WFE, you would

need to re-authenticate• Having the Distributed Cache service means that sticky sessions are no

longer required when using SAML or FBA claims!

Authentication Infrastructure

• You can choose the characters for the claim type and there is no enforcement on the ordering of claim types• Pre-populate the custom claim types and characters across all farms• Install the claim providers that use those custom claim types in any

order • You can add multiple token signing

certificates to the SharePoint STS• Useful in S2S scenarios• Use the Set-SecurityTokenServiceConfig cmdlet

New Claims Features

• There is significantly more logging provided to help troubleshoot authentication issues. You can see things like:• Adding / removing FedAuth cookies from the cache• Where authentication requests get redirected• Which claims providers were used and which were not• Reason why a FedAuth cookie failed to be used (i.e. expiration, failure

to decrypt, etc.)

Authentication Logging

OAuth - Application Authentication

• Definition: OAuth enables users to approve an application to act on their behalf without sharing their user name and password.

• For example, it enables users to share their resources or data (contact list, documents, photos, videos and so on) that are stored on one site with another site• The key is that users don’t have to provide their credentials each time

What is OAuth

• OAuth is used only for access tokens; it is not used for sign-in tokens

• Only WS-Fed is supported for sign-in, just like SharePoint 2010

• That means you won’t see any OAuth providers listed in the user sign-in page, the Authentication Provider section in Central Admin, or the People Picker

What OAuth is Not

• OAuth allows users to authorize SharePoint to provide access tokens to apps that can be used to retrieve data from SharePoint

• Each token can be used to access:• A specific site• A specific resource (for example, documents from a folder)• For a defined duration (for example, 30 minutes)

• This enables a user to grant an app access to their information in SharePoint without sharing their username and password, or all of the data that they have in SharePoint

How Does OAuth Work

• A user signs in to SharePoint 2013 and is authenticated • The user then opens a provider hosted app (i.e. in Azure)• The app was granted permission at install time by a user (not necessarily the current user) to

access a SharePoint list• The app is rendered as an embedded iFrame or loaded full

frame by POSTing the necessary context information • That app then calls back to SharePoint to access the

SharePoint resources on behalf of the user• When it calls back it includes a token for both the current

user and app• SharePoint validates that BOTH have rights to access the content

Typical OAuth Scenario for Provider Hosted App

OAuth FlowSTS (ACS)

SharePoint ServerClient

Intranet.contoso.com

7- Access token

10. IFrame contents

5. Request IFrame contents

4. Page - IFrame 9. SharePoint data

8. Request – Access token1.

Request

2. Request context token

3. Signed context token 6.

Refreshtoken

Application Permissions

• An app requests the permissions that it needs during installation

• The developer of an app must request, through the app manifest file, the permissions it needs

• An app must be granted permissions by the user who is installing it

• Users can grant only the permissions that they have; the user installing the app must be able to grant all permissions required or install fails

• You must be at least a Site Owner in order to install an app

Granting App Permissions

• App rights are set when:• Consent is given and an app is installed• An app is explicitly granted permission by a tenant administrator or

SPWeb administrator• An app is removed

• Once provisioned, the rights for an app cannot change – they can only be revoked in whole• This ensures the app will not have to account for missing rights, i.e.

become broken after installation

Setting App Rights

• An app uses permission requests to specify the permissions that it needs

• The requests specify both the rights and scope which are needed

• Scopes indicate where in the SharePoint hierarchy a permission request applies. SharePoint supports four different scopes for content :• SPSite—site collection• SPWeb—website• SPList—list• Tenancy—the tenancy scope is at http://<sharepointserver>/<content>/<tenant>/

• There are also scopes for things like performing search queries, accessing taxonomy data, user profiles, etc.

App Rights and Scopes

• If an app is granted permission to a scope, the permission applies to all children of the scope• If an app is granted perms to an SPWeb, the app is also granted perms to each SPList in the

SPWeb, and all SPListItems in each list, but NOT each subweb• Permission rights indicate what an app is permitted to do

within a scope. SharePoint supports four rights levels for content (there are others for things like search, term store, etc.):• Read-Only• Write• Manage• Full Control

• Unlike SharePoint user roles, these rights levels are not customizable

App Rights and Scopes (cont.)

• You can choose to have each app use its own cert, or have apps share a cert

• Each cert that’s used needs to be trusted by SharePoint using the New-SPTrustedSecurityTokenIssuer cmdlet

• That is important if you ever want to stop trusting an app• If each app has it’s own cert, you just stop trusting that cert• If apps share a cert, then you need to:• Stop trusting the cert• Have all the other apps you still trust start using a new cert• Configure SharePoint to start trusting the new cert

Using Certificates for High Trust Apps

• If you use a single cert there are certain considerations you should be aware of:• Use the IsTrustBroker flag when you create your

SPTrustedSecurityTokenIssuer• Required to enable one certificate to be used by multiple apps

• Do NOT use the same ClientId for each application• The IssuerId can be the same – that’s the identifier for the

SPTrustedSecurityTokenIssuer• The ClientId though should uniquely identify each application• Each app will have its own appPrincipal, which is where the ClientId comes from

Using a Single Certificate for High Trust Apps

Setting Up High Trust AppsTom Wisnowski

Server to Server Authentication (aka S2S) -OAuth Between Servers

• Server to Server (S2S) is a scenario for application to application OAuth• It involves the “well known app principals” that are allowed to delegate

a user identity that SharePoint will accept• Well known app principals for Wave 2013 are: SharePoint, Exchange,

Lync, Azure Workflow Server

Server to Server Authentication

• SharePoint S2S depends on mapping to a user account through the user profile application• That means it’s important to have UPN, SMTP, and SIP attributes up to

date in the UPA• SharePoint constructs a token for a user when needed for an S2S

request• The actual claim set the user gets though is dependent on several

factors – as explained on next slide

S2S and User Profiles

• A full claim set requires you to do profile imports for other claims that are used for securing resources• UPN, SMTP and SIP, as well as group memberships for AD comes from

profile sync• A sync connection or custom sync job is needed from the membership

store to create a profile for each FBA user and populate a UPN, SMTP and/or SIP attribute. The FBA role provider is “invoked” automatically to get role claims

S2S User Profile Mappings

• A sync connection or custom sync job is needed to create a profile for SAML users. In addition you must write code for any additional role claims that come from SAML identity providers and sync them to a “Group” membership in the User Profile system.• NOTE: Many custom claims are not role claims; in order to have them included

when a user is rehydrated, the claims must be added via a custom claim provider augmentation

• Custom claims providers are “invoked” to get other claims that are added via augmentation

S2S User Profile Mappings (cont.)

• Enabling this server-to-server application authentication opens up some very interesting features; some examples:• eDiscovery – You can select a combination of SharePoint content and

Exchange mailboxes to include as part of a legal hold. S2S allows SharePoint and Exchange to connect to retrieve that mailbox data for indexing

• Task Management – You can create tasks in Outlook and have them show up in your personal site in SharePoint; you can edit them there and have the changes synced back to Outlook

• Team Mailboxes – they exist in Exchange, but are rendered and shared in SharePoint

How is S2S Platform Used

Site Mailbox S2STom Wisnowski

• Authentication modes in SharePoint 2013• OAuth• Server to Server Authentication

Summary

Evaluate this session now on MySPC using your laptop or mobile device: http://myspc.sharepointconference.com

MySPC

Q&A

© 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.