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

Spencer Harbar
About Spencer Harbar

Microsoft Certified Solutions Master | SharePoint
Microsoft Certified Architect | SharePoint 2010
Mi...
Agenda
Level Set &
AuthN/Z
Primer

Windows
Authentication

Tusted Claims
Providers

Service
Delegation

Server to
Server &...
Level Set
Level Set
Authentication
(AuthN)
Authorization
(AuthZ)
•

• the mechanism to securely identify users

• the mechanism to d...
Authentication models
•

Core concepts that underpin every web application, ever!

Trusted
Subsystem

Impersonation
/ Dele...
Claims architecture
Identity versus Authentication
Claims-based Identity
• Enables a “new” class of application services

Claims-based Authent...
SharePoint Authentication
• Two Authentication Modes for Web Applications
– “Classic” and Claims

• No other SharePoint Au...
Delegation
• Basic Delegation
– Direct delegation from web application to data
– e.g. BCS to SQL Server
– e.g. IIS to IIS
...
Identity Management (“IdM”)

Whether you like it or not!

User Sign In
Service Interaction
Pretty much every
investment ar...
Identity Management (“IdM”)
Windows Authentication
Windows authentication
• All of the following applies whether using
Classic or Windows Claims
– Authentication process is ...
Surely Claims means Kerberos is dead?
Claims != R.I.P. Kerberos
• Windows Claims is still Windows
Authentication
– And therefore potentially Kerberos

• Claims ...
Why you might need Kerberos?

Inter server communication
End user authentication
NTLM viewed as “weak” in
some circles
Sec...
Trusted Claims Providers
Trusted Claims Provider Sign In
So what should I use?
Identity Normalization (sort of!)
-Classic
NT Token

Windows Identity

-Claims
NT Token

Windows Identity

ASP.Net (FBA)
S...
Choosing Your Authentication Method
• Not all Claims are created equal!
• The real question is:
Windows Claims versus
FBA ...
Claims limitations
• The “list” is still being put together
• Vast majority of gaps in 2010 have been
bridged
– However us...
Service Delegation
Service interoperation
Web Front End

Sign-In

Windows Identity
Claims Identity

Web part, etc.

SharePoint STS
1
2

Clien...
Claims Delegation architecture
• Kerberos Constrained Delegation (KCD)
with Protocol Transition
WEB

Classic /
Claims

Cla...
Server to Server
Server to Server
 Server to Server (S2S) is a scenario for application
to application OAuth
 It involves the “well known...
S2S and User Profiles
 SharePoint S2S depends on mapping to a user
account through the user profile application
 That me...
How is S2S Platform Used
eDiscovery – You can select a combination of SharePoint
content and Exchange mailboxes to includ...
Office Web Applications
• Proprietary Authorization
– Not S2S – the “OWA secret handshake”

• Hence OWA 2013 can NOT be co...
“App” Authorization
What is OAuth
 Definition: OAuth enables users to approve an
application to act on their behalf without sharing their
use...
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...
Example OAuth Scenario
• Cloud Hosted Apps

YES

Start

User logs into
SharePoint site

Is App Using
ACS?
NO

SharePoint g...
Be ready for pushback!
• “When compared with OAuth 1.0, the 2.0 specification is
more complex, less interoperable, less us...
Office 365
Identity options
Online IDs

Online IDs & DirSync

Federated IDs & DirSync

Appropriate for
• Smaller orgs without AD
on-p...
“Hidden” Concepts
• Anything other than Microsoft IDs is a long
term commitment to identity co-existence
– DirSync and Fed...
Identity federation
AD Considerations
Structure

Description

Considerations

Matching domains Internal domain and external
domain are the sam...
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
A...
THANK YOU
SPCA2013 - It’s Me, and Here’s My ProofIdentity & Authentication in SharePoint 2013 and Office 365
SPCA2013 - It’s Me, and Here’s My ProofIdentity & Authentication in SharePoint 2013 and Office 365
SPCA2013 - It’s Me, and Here’s My ProofIdentity & Authentication in SharePoint 2013 and Office 365
Upcoming SlideShare
Loading in...5
×

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

1,481

Published on

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

Published in: Technology
1 Comment
1 Like
Statistics
Notes
No Downloads
Views
Total Views
1,481
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
35
Comments
1
Likes
1
Embeds 0
No embeds

No notes for slide

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

  1. 1. It’s Me, and Here’s My Proof Identity & Authentication in SharePoint 2013 & Office 365 Spencer Harbar
  2. 2. 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
  3. 3. Agenda Level Set & AuthN/Z Primer Windows Authentication Tusted Claims Providers Service Delegation Server to Server & Office Web Apps ”App” Authorization Office 365
  4. 4. Level Set
  5. 5. Level Set Authentication (AuthN) Authorization (AuthZ) • • the mechanism to securely identify users • the mechanism to determine what level of access a particular authenticated user should have to secured resources Confusing these two concepts is extremely common
  6. 6. Authentication models • Core concepts that underpin every web application, ever! Trusted Subsystem Impersonation / Delegation
  7. 7. Claims architecture
  8. 8. Identity versus Authentication Claims-based Identity • Enables a “new” class of application services Claims-based Authentication • End user sign-in
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. Identity Management (“IdM”)
  13. 13. Windows Authentication
  14. 14. 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!
  15. 15. Surely Claims means Kerberos is dead?
  16. 16. 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
  17. 17. Why you might need Kerberos? Inter server communication End user authentication NTLM viewed as “weak” in some circles Security policies often dictate “Kerberos” requirement NTLM is very chatty Reduce authentication traffic Reduce impact on infrastructure Multi domain scenarios Multi forest scenarios Applications or Services that require delegation RSS Viewer Excel Services to external sources ANY service app to external sources! Custom Solutions
  18. 18. Trusted Claims Providers
  19. 19. Trusted Claims Provider Sign In
  20. 20. So what should I use?
  21. 21. Identity Normalization (sort of!) -Classic NT Token Windows Identity -Claims NT Token Windows Identity ASP.Net (FBA) SQL, LDAP, Custom … SAML Token Claims Based Identity SPUser SAML1.1+ ADFS, etc.
  22. 22. Choosing Your Authentication Method • Not all Claims are created equal! • The real question is: Windows Claims versus FBA Claims versus SAML Claims
  23. 23. 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!
  24. 24. Service Delegation
  25. 25. Service interoperation Web Front End Sign-In Windows Identity Claims Identity Web part, etc. SharePoint STS 1 2 Client Proxy 4 {Token} 3 5 6 WS-*/SAML Trust Claims Token App Server SAML/OAuth Windows Identity Framework SAML {Claims Principal} Service Authorization SharePoint Service SharePoint STS Windows Identity Framework Kerberos C/D C2WTS Secure Store Service Credentials Legacy LOB
  26. 26. Claims Delegation architecture • Kerberos Constrained Delegation (KCD) with Protocol Transition WEB Classic / Claims Claims W3WP Excel Web Access Data Source APP Windows AuthN (Kerb) ES SA Delegation Path C2WTS
  27. 27. Server to Server
  28. 28. 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
  29. 29. 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
  30. 30. 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
  31. 31. 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 SharePoint Farm 1 Office Web App 2 Office Web Apps 3
  32. 32. “App” Authorization
  33. 33. 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
  34. 34. 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
  35. 35. Example OAuth Scenario • Cloud Hosted Apps YES Start User logs into SharePoint site Is App Using ACS? NO SharePoint gets context token for App with user info from ACS Page loads, SharePoint posts to app with context token App uses ID and secret to get access token from ACS Page loads, either iFrame or full page to App 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
  36. 36. 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
  37. 37. Office 365
  38. 38. Identity options Online IDs Online IDs & DirSync Federated IDs & DirSync Appropriate for • Smaller orgs without AD on-premises Appropriate for • Medium/large orgs with AD on-premises Appropriate for • Larger enterprise orgs with AD on-premises Pros • No servers required onpremises Pros Pros • Users and groups • SSO with corporate mastered on-premises credentials • It enables coexistence • IDs mastered onscenarios premises Cons Cons • Password policy • No SSO controlled on-premises • No SSO • No two-factor • Two-factor authentication authentication • No two-factor possible authentication • Two sets of credentials to • It enables coexistence manage with differing • Two sets of credentials to scenarios password policies manage with differing password policies Cons • IDs mastered in the cloud • Single server deployment • High availability server deployments required
  39. 39. “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
  40. 40. Identity federation
  41. 41. 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 subdomains 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 • Multi-forest Multiple AD forest “External” FIM + Guidance • AD FS QFE—to resolve this issue. Requires new switch in Windows PowerShell SupportMultipleDomain
  42. 42. Office 365 Sync using FIM2010 Extend Metaverse Schema
  43. 43. Office 365 Sync using FIM2010
  44. 44. Wrap up
  45. 45. 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
  46. 46. THANK YOU
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×