Active or Passive Federation in the Enterprise

1
Active or Passive Federation in the Enterprise

• Steve Plank Microsoft

2
Agenda

• Overview of Enterprise Active and Passive
  Federation
• Individual Group Discussions (led)
• Large Group Debate

3
Domain-based Identity Model
Trust

• In the beginning, identity providers created
  principals users and services

4
The Importance of being Open and Interoperable

• You can federate using proprietary software
• However, open standards give scale and reach
• Open, standard protocols e.g. HTTP, WS-
• Open, standard token formats e.g. SAML, XrML
• Let each system use the optimal identity system
  then connect through open standards

5
Federation Flow
Fabrikam - Resource
Contoso - Account
Trust
Federation Server A
Federation Server R
Gimme an R token!
A token
Gimme a token!
Contoso\Lisa
Identify yourself!
Identify yourself!
The App
A token
R token
Do work for me!
R token
Heres the work you wanted!
Get an R token from resource server first!
6
Active Directory Federation Services

• Federates the Windows domain model
• Active Directory or Active Directory Lightweight
  Directory Services
• Open and interoperable
• WS-Federation Passive Requestor Profile protocol
• SAML 1.1 security tokens
• With
• IBM Tivoli Federated Identity Manager, PingId,
• BMC, CA eTrust SiteMinder, Shibboleth

7
ADFS Limitations

• Browser only no web services
• Home realm discovery
• Domain-centric viewpoint
• All trust decisions made centrally, one-by-one
• Doesnt scale users not involved
• Why not make it easy enough that users can do it
  themselves?
• E.g. two business groups working together

8
Identity Metasystem Protocols
User
User approves release of token
7
Client
User selects an IP
4
Client wants to access an RP resource
1
Request security token
3
Which IPs can satisfy requirements?
5
RP provides identity requirements
2
6
Return security token based on RPs requirements
Token released to RP
8
Identity Provider
Relying Party
9
Shift of Emphasis

• The user is in control
• Home realm discovery is selecting an IP
• Identity Selector
• Allows the user to select an identity provider
• Coordinates protocol flow and user experience

10
ImplementationX.509, Web and Web Service
Protocols

• Encapsulation of tokens
• SOAP messages, WS-Security, X.509 v3 certificates
• Retrieval of requirements and capabilities
• WS-SecurityPolicy WS-MetadataExchange
• Token issuance and claims transformation
• Security Token Services, WS-Trust
• Browser-based applications
• Messages encoded in HTTP

www.microsoft.com/interop/osp
11
Windows CardSpace Identity Selector Software

• Easily and safely manage your digital identities
• Authenticate with web sites and web services

Safer
Easier

• No usernames and passwords
• Consistent login and registration

• Avoid phishes
• Multi-factor authentication

Built on WS- Web Service Protocols
12
Information Cards

• Signed XML metadata describing an identity
  provider, for use by identity selectors
• Includes
• An image to render as a card in a UI
• STS endpoint reference(s)
• STS authentication method(s)
• STS token type(s)
• STS claim(s)

13
CardSpace and the Enterprise

• User-centric Federation
• Information Cards
• Standardized and ubiquitous
• Flexible, agile user-driven relationships
• Anti-phishing and information minimalization
• Security Token Services
• Identity service which connects systems

14
Flow with an Identity Selector
Fabrikam - resource
Contoso - account
Trust
AD/STS
Linux STS
Gimme an R token!
SAML
Gimme a token!
Contoso\Lisa
Identify yourself!
The App
Identify yourself!
SAML
R token
Do work for me!
R token
Heres the work you wanted!
Policy Get R token from my STS!
15
Key Trust is Local

• Relying Party decides who accesses a resource
• This is a business decision not an IT decision
• But it has been too hard to do
• Relationships are often personal
• We want Enterprise policy and relative autonomy
  of business units
• Chief role of Information Cards in the
  Enterprise
• Devolve access control to the true resource owners

16
When to use Cards?

• Integrated authentication
• Nothing gets in the way no username and
  password just use the app
• Perfect inside the firewall
• Information Cards
• Just select a card no username and password
• User in control, manages privacy and consent
• Cards represent contexts and roles
• Your work information card is the digital
  equivalent of your employee badge
• Explicit security boundaries multi-factor
  authentication

17
Future Dual architectures?

• Suppose Information Cards become progressively
  more ubiquitous
• E.g. if large internet sites enable billions of
  users
• There will be increasing pressure to adopt
  Information Cards for external relationships
• Is it desirable to have one architecture inside
  the Enterprise and one outside in the age of
  de-perimeterization?

18
ADFS "2"

• ADFS 2 makes federation easy
• Create and manage federation partnerships
• Security Token Service with WS-Trust and WS-Fed
• Policy-driven authentication and token issuance
• Helper classes to build claims-aware applications
• Information Card provisioning

19
Conclusion

• Information Card architecture provides benefits
  to the federated enterprise
• However User is in control
• Simplification and visualization allow IT to
  devolve control to resource owners
• Setting access control policy for relying parties
  becomes simple
• Ultimately, we reap the benefits of a single user
  experience at home and in the enterprise

20
Review

• Overview of Enterprise Identity
  Challenges/Solutions
• Individual Group Discussions (led)
• Large Group Debate