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

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

3. 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

4. Agenda
Level Set &
AuthN/Z
Primer
Windows
Authentication
Tusted Claims
Providers
Service
Delegation
Server to
Server & Office
Web Apps
”App”
Authorization
Office 365

5. Level Set

6. 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

7. Authentication models
•
Core concepts that underpin every web application, ever!
Trusted
Subsystem
Impersonation
/ Delegation

8. Claims architecture

9. Identity versus Authentication
Claims-based Identity
• Enables a “new” class of application services
Claims-based Authentication
• End user sign-in

10. 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

11. 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

12. 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

13. Identity Management (“IdM”)

14. Windows Authentication

15. 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!

16. Surely Claims means Kerberos is dead?

17. 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

18. 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

19. Trusted Claims Providers

20. Trusted Claims Provider Sign In

21. So what should I use?

22. 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.

23. Choosing Your Authentication Method
• Not all Claims are created equal!
• The real question is:
Windows Claims versus
FBA Claims versus
SAML Claims

24. 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!

25. Service Delegation

26. 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

27. 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

28. Server to Server

29. 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

30. 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

31. 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

32. 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

33. “App” Authorization

34. 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

35. 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

36. 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

37. 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

38. Office 365

39. 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

40. “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

41. Identity federation

42. 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

43. Office 365 Sync using FIM2010
Extend Metaverse
Schema

44. Office 365 Sync using FIM2010

45. Wrap up

46. 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

47. THANK YOU