spca2013 - it’s me, and here’s my proofidentity & authentication in sharepoint 2013 and...

It’s Me, and Here’s My ProofIdentity & Authentication in SharePoint 2013 & Office 365

Spencer Harbar

About Spencer Harbar

Microsoft Certified Solutions Master | SharePoint

Microsoft Certified Architect | SharePoint 2010

Microsoft Certified Solutions Master | SharePoint Instructor & Author

Microsoft Certified Master | SharePoint 2010

Microsoft Certified Master | SharePoint 2007

Most Valuable Professional | SharePoint Server

SharePoint Patterns & Practices Advisory Board Member

Works with Microsoft’s largest enterprise customers

Works with SharePoint Product Group on Readiness

Author for MSDN & TechNet

Agenda

Level Set &

AuthN/Z

Primer

Windows

Authentication

Tusted Claims

Providers

Service

Delegation

Server to

Server & Office

Web Apps

”App”

Authorization

Office 365

Level Set

Level Set

• the mechanism to securely identify usersAuthentication

(AuthN)

• the mechanism to determine what level of

access a particular authenticated user should

have to secured resources

Authorization

(AuthZ)

• Confusing these two concepts is extremely common

Authentication models

• Core concepts that underpin every web application, ever!

Trusted

Subsystem

Impersonation

/ Delegation

Claims architecture

Identity versus Authentication

Claims-based Identity

• Enables a “new” class of application services

Claims-based Authentication

• End user sign-in

SharePoint Authentication

• Two Authentication Modes for Web Applications

– “Classic” and Claims

• No other SharePoint Authentication Providers!

• Classic Mode is deprecated

– Claims Mode is the default

– Classic only available via Windows PowerShell

– Highly likely that Classic will be removed in a future version

– Classic still required for scenarios that use basic delegation without introducing supportability concerns

Delegation

• Basic Delegation

– Direct delegation from web application to data

– e.g. BCS to SQL Server

– e.g. IIS to IIS

• Service Delegation

– “Middle tier” delegation from service to data

– e.g. Excel Services to Analysis Services

Identity Management (“IdM”)

Whether you like it or not! User Sign In

Service Interaction

Pretty much every investment area relies on Profiles for core functionality

App AuthZ, S2S, etc

Primarily a political endeavor, NOT a technical one

No toolset from any vendor will change this

IdM consulting skills a must have for successful implementation

Identity Management (“IdM”)

Windows Authentication

Windows authentication

• All of the following applies whether using

Classic or Windows Claims

– Authentication process is identical

– In Windows Claims, additional work is done by SPWindowsClaimsAuthenticationHttpModule

– Basic Delegation only works with Classic!

Surely Claims means Kerberos is dead?

Claims != R.I.P. Kerberos

• Windows Claims is still Windows Authentication

– And therefore potentially Kerberos

• Claims makes cross organization/product boundary authentication simpler

– Org to Org, Org to Cloud, Cloud to Cloud

• Many functional constraints today with Claims

– Improved somewhat with SharePoint 2013

– Many external services are not yet claims aware

Why you might need Kerberos?

Inter server communicationEnd user authenticationNTLM viewed as “weak” in some circlesSecurity policies often dictate “Kerberos” requirement

NTLM is very chattyReduce authentication trafficReduce impact on infrastructureMulti domain scenariosMulti forest scenarios

Applications or Services that require delegationRSS ViewerExcel Services to external sourcesANY service app to external sources!Custom Solutions

Trusted Claims Providers

Trusted Claims Provider Sign In

So what should I use?

Identity Normalization (sort of!)

NT Token

Windows Identity

ASP.Net (FBA)

SQL, LDAP,

Custom …

SAML Token

Claims Based Identity

SPUser

NT Token

Windows IdentitySAML1.1+ADFS, etc.

-Classic -Claims

Choosing Your Authentication Method

• Not all Claims are created equal!

• The real question is:

Windows Claims versus

FBA Claims versus

SAML Claims

Claims limitations

• The “list” is still being put together

• Vast majority of gaps in 2010 have been bridged

– However usually with a “workaround”

• “edge” scenarios are still troublesome

• Much guidance is brought over from 2010

– E.g. Visio Services and C2WTS

– Which is now incorrect or invalid

– Be careful! Test! Test! Test!

Service Delegation

Service interoperation

Web Front End

Web part, etc.

Client Proxy{Token}

SharePoint STS

SharePoint Service

Windows Identity

Claims Identity

Trust

1

2

34

Claims Token

{Claims Principal}

Sign-In

Service

Authorization

5

SharePoint STSApp Server

Windows

Identity

Framework

Windows

Identity

Framework

6

C2WTS

Secure Store Service

SAML/OAuth

WS-*/SAML

SAML

Kerberos C/D

Credentials Legacy

LOB

Claims Delegation architecture

• Kerberos Constrained Delegation (KCD)

with Protocol Transition

W3WP ES SA

C2WTS

WEB APP Data Source

Excel Web

Access

Classic /

Claims

Windows

AuthN

(Kerb)

Claims

Delegation Path

Server to Server

Server to Server

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

Expect more services/products to use this approach going

forward

S2S and User Profiles

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

How is S2S Platform Used

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

Workflow Manager – make use of external platform for

workflow hosting and execution

Office Web Applications

• Proprietary Authorization

– Not S2S – the “OWA secret handshake”

• Hence OWA 2013 can NOT be consumed by SharePoint 2010

• Hence OWA 2013 can open IRMd items in a SharePoint library

Office Web Apps

SharePoint Farm

Office Web

App

1

23

“App” Authorization

What is OAuth

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 OAuth is Not

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

Example OAuth Scenario

• Cloud Hosted Apps

StartUser logs into

SharePoint site

Page loads,

SharePoint

posts to app

with context

token Is App Using

ACS?

SharePoint gets

context token

for App with

user info from

ACS

App creates an

access token

using app’s

trusted cert

App presents

its access token

to SharePoint

and requests

data

SharePoint

validates rights

and returns

data if rights

exist

App uses data

it gets back to

render HTML

End

NO

YES

App uses ID

and secret to

get access

token from

ACS

Page loads,

either iFrame

or full page to

App

Be ready for pushback!

• “When compared with OAuth 1.0, the 2.0 specification is

more complex, less interoperable, less useful, more

incomplete, and most importantly, less secure.

To be clear, OAuth 2.0 at the hand of a developer with deep

understanding of web security will likely result is a secure

implementation. However, at the hands of most developers

– as has been the experience from the past two years – 2.0

is likely to produce insecure implementations.”

• Eran Hammer – lead author and editor of the OAuth 2.0 standard

Office 365

Identity options

Online IDs Online IDs & DirSync Federated IDs & DirSync

Appropriate for

• Smaller orgs without AD on-premises

Pros

• No servers required on-premises

Cons

• No SSO

• No two-factor authentication

• Two sets of credentials to manage with differing password policies

• IDs mastered in the cloud

Appropriate for

• Medium/large orgs with AD on-premises

Pros

• Users and groups mastered on-premises

• It enables coexistence scenarios

Cons

• No SSO

• No two-factor authentication

• Two sets of credentials to manage with differing password policies

• Single server deployment

Appropriate for

• Larger enterprise orgs with AD on-premises

Pros

• SSO with corporate credentials

• IDs mastered on-premises

• Password policy controlled on-premises

• Two-factor authentication possible

• It enables coexistence scenarios

Cons

• High availability server deployments required

“Hidden” Concepts

• Anything other than Microsoft IDs is a long term commitment to identity co-existence

– DirSync and Federation the only sensible option really

– Implementation may change, but the core concepts will remain

• The “journey” to the cloud requires more infrastructure on premises

– And potentially expensive preparation of existing infrastructure and desktops

Identity federation

AD Considerations

Structure Description Considerations

Matching domains Internal domain and external

domain are the same

i.e. contoso.com

No special requirements

Sub-domain Internal domain is a sub-domain of

the external domain

i.e. corp.contoso.com

Requires domains to be registered

in order, primary and then sub-

domains

Local domain Internal domain is not publicly

“registered”

i.e. contoso.local

Domain ownership can’t be

proved, must use a different

domain:

• Requires all users to get new

UPN

• Use SMTP address if possible

Multiple distinct

UPN suffixes in

single forest

Mix of users having login UPNs

under different domains

i.e. contoso.com and fabrikam.com

• AD FS QFE—to resolve this

issue.

• Requires new switch in

Windows PowerShell

SupportMultipleDomain

Multi-forest Multiple AD forest “External” FIM + Guidance

Office 365 Sync using FIM2010

Extend Metaverse

Schema

Office 365 Sync using FIM2010

Wrap up

Summary

• AuthN/Z fundamentals

• The importance of Identity Management with

SP2013

• Windows and Trusted Claims Provider

Authentication

• Service Delegation Scenarios

• Server to Server and Office Web Apps

• ”App” Authorization

• Office 365 Identity and Sign In

THANK YOU