Your SlideShare is downloading. ×
SPCA2013 - It’s Me, and Here’s My ProofIdentity & Authentication in SharePoint 2013 and Office 365
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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


Published on

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

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

Published in: Technology

1 Comment
1 Like
No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. It’s Me, and Here’s My Proof Identity & Authentication in SharePoint 2013 & Office 365 Spencer Harbar
  • 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. Agenda Level Set & AuthN/Z Primer Windows Authentication Tusted Claims Providers Service Delegation Server to Server & Office Web Apps ”App” Authorization Office 365
  • 4. Level Set
  • 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. Authentication models • Core concepts that underpin every web application, ever! Trusted Subsystem Impersonation / Delegation
  • 7. Claims architecture
  • 8. Identity versus Authentication Claims-based Identity • Enables a “new” class of application services Claims-based Authentication • End user sign-in
  • 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. 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. 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. Identity Management (“IdM”)
  • 13. Windows Authentication
  • 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. Surely Claims means Kerberos is dead?
  • 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. 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. Trusted Claims Providers
  • 19. Trusted Claims Provider Sign In
  • 20. So what should I use?
  • 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. Choosing Your Authentication Method • Not all Claims are created equal! • The real question is: Windows Claims versus FBA Claims versus SAML Claims
  • 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. Service Delegation
  • 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. 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. Server to Server
  • 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. 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. 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. 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. “App” Authorization
  • 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. 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. 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. 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. Office 365
  • 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. “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. Identity federation
  • 41. AD Considerations Structure Description Considerations Matching domains Internal domain and external domain are the same i.e. No special requirements Sub-domain Internal domain is a sub-domain of the external domain i.e. 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. and • Multi-forest Multiple AD forest “External” FIM + Guidance • AD FS QFE—to resolve this issue. Requires new switch in Windows PowerShell SupportMultipleDomain
  • 42. Office 365 Sync using FIM2010 Extend Metaverse Schema
  • 43. Office 365 Sync using FIM2010
  • 44. Wrap up
  • 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. THANK YOU