Federated and fabulous identity


Published on

A high level overview of federated identity.

Published in: Technology
1 Like
  • Be the first to comment

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

No notes for slide
  • Digital Identity – A digital representation of a principal (or group of principals) that is unique to that principal (or group), and that acts as a reference to that principal (or group). For example, an email address MAY be treated as a digital identity, just as a machine’s unique IP address MAY also be treated as a digital identity, or even a generated unique identifier. In the context of this document, the term identity is often used to refer to a digital identity. A principal may have multiple digital identities,
  • Logger inn på STS
  • Federated and fabulous identity

    1. 1. Federated and fabulous identity André N. Klingsheim - @klingsen AppSec AS Dataforeningen 18.09.2013
    2. 2. Outline • Federated Identity • WS-Federation • Architectural advantages • Building federated identity systems • Demo
    3. 3. Federated identity • Federation – A federation is a collection of realms that have established a producer-consumer relationship whereby one realm can provide authorized access to a resource it manages based on an identity, and possibly associated attributes, that are asserted in another realm*.  TL;DR: A company can give access to a resource based on an identity asserted by another company. • Identity – The identity of an individual is the set of information associated with that individual in a particular computer system.**  Can be extended to system entities, such as computers/service accounts.  The term "principal" is used to refer to system entities/individuals in computer systems. ** S. T. Kent and L. I. Millett, editors, Who Goes There? Authentication Through the Lens of Privacy, The National Academies Press, 2003 * Web Services Federation Language (WS-Federation), Version 1.1, December 2006
    4. 4. The problem at hand User Collaboration website https://collaboration.partner.com My company (Realm) Partner company (Realm)
    5. 5. The classic approach • Partner company maintains a user database for its application • Each user from our company is assigned an account for partner's application • Typical login: username/password • Many partner websites -> many usernames/passwords • Challenging to maintain these userIDs  User quits the company, internal account closed. What about accounts in all partnering companies' applications?  Challenging to keep track of who has access to what  No central management of Ids • Federated identity to the rescue!
    6. 6. WS-Federation • Web Services Federation Language  Contributors: Microsoft, IBM, Novell, Verisign and more.  Industry standard, freely available.  Builds upon WS-Security and WS-Trust. • Defines mechanisms to allow different security realms to federate • Focused on web services • Also includes specification for Web (Passive) Requestors  Enables the WS-Federation protocol to be run through a web browser  Involves real people!  We'll be focusing on the web scenario.
    7. 7. The building blocks • Trust - Trust is the characteristic that one entity is willing to rely upon a second entity to execute a set of actions and/or to make set of assertions* about a set of subjects and/or scopes. • Claims based identity • Claim – A claim is a declaration made by an entity (e.g. name, identity, key, group, privilege, capability, etc). • Means to (securely) communicate identity information between realms • Security Token – A security token represents a collection (one or more) of claims. * Claim and assertion are synonyms
    8. 8. Important roles • Identity Provider (IP) – An Identity Provider is an entity that acts as an authentication service to end requestors and a data origin authentication service to service providers. • Security Token Service (STS) - A Security Token Service is a Web service that provides issuance and management of security tokens. • Relying Party – A Web application or service that consumes Security Tokens issued by a Security Token Service.
    9. 9. Security token • Contains claims about the user  Typical claims: Username, user's name, e-mail address, groups (for authz) • Signed by STS  RP can verify that it was issued by a trusted STS  Tamper-proof • Lifetime (valid from/to) • Intended for a particular RP • Can also be encrypted -> only the intended RP can decrypt it • Can be on different formats, often SAML
    10. 10. Security token "IRL"
    11. 11. Federation "IRL" User Norway USA IP STS Relying party
    12. 12. User My company (Realm) Partner company (Realm) IP STS Relying party Authenticate Relying party Another partner company (Realm)
    13. 13. Architectural advantages • Separates authentication logic from application • Enables single-sign-on for a suite of applications  Provides a seamless experience across stand-alone applications • Yields great flexibility when building e.g. an online bank  Different services can be provided through separate applications  Simplifies releases  Makes it easier for multiple teams to work in parallell  Opens the possibility to host different applications in separate environments  E.g. some apps hosted locally, some apps hosted in the cloud  Simplifies integration of third party applications  Facilitates privacy-by-design, carefully selecting claims provided to various applications
    14. 14. How we used to do things Authentication Accounts/payment Stocks/fund Debit/credit cards Loans Personal finance Sample online banking application
    15. 15. How we can do things now Sample online banking application suite Authentication IP/STS Personal finance Accounts/payment Stocks/fund Debit/credit cards Loans RPs
    16. 16. A few challenges • Providing flexibility in common functionality  Handling change to "shared" menus etc. • Care must be taken with regards to session management
    17. 17. Building federated identity systems • We need minimum three things, an IP, an STS, and an RP • The RP usually contains the features (customer value). Everyone wants this! • IPs and STSs, you build because you have to (though some of us thinks it's great fun) • Want to spend as much time as possible on building the fun stuff – features. • Authentication as a service?
    18. 18. Windows Identity Foundation • Framework for building identity-aware applications • Included in the .NET Framework 4.5  Available as a separate library before .NET 4.5 • Provides APIs for building Relying Parties and STSs  Provides a programming model for working with claims based identity • Provides out-of-the-box functionality for RPs
    19. 19. AD FS • Active Directory Federation Services • AD-integrated STS • Included in Windows Server 2008/2012 • Enables federation of AD-identities • Seamless experience for users
    20. 20. AD FS User AD FS https://adfs.domain.com/STS AD Collaboration website https://collaboration.partner.com My company Partner company STSSTSIP RP
    21. 21. ACS • Windows Azure Active Directory Access Control (aka ACS) • Cloud based service • Facilitates authentication and manages authorization of users • Supports several identity providers  AD FS  Windows Live ID / Google / Yahoo! / Facebook • Windows Identity Foundation integration
    22. 22. ACS User Usefulwebsite https ://usefulwebsite .mycompany .com ACS Windows Live ID Google My companyCloud
    23. 23. Demo!
    24. 24. Thank you! André N. Klingsheim - @klingsen AppSec AS www.dotnetnoob.com
    1. A particular slide catching your eye?

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