Copyright 2006 Archistry Limited. All Rights Reserved. SOA Federated Identity Management How much do you really need? Andrew S. Townley Founder and Managing Director Archistry Limited

Public Information 2 Copyright 2006 Archistry Limited. All Rights Reserved. Agenda  Definitions  Business drivers for federated identity  Approaches to providing federated identity  Technical considerations  Questions

Public Information 3 Copyright 2006 Archistry Limited. All Rights Reserved. Definitions  Federated system – integrates existing, possibly heterogeneous systems while preserving their autonomy  Association autonomy – the ability of a component system to decide whether and how to share its operations and resources with other systems  Federated identity – a shared name identifier agreed between partner services in order to share information about the user across organizational boundaries

Public Information 4 Copyright 2006 Archistry Limited. All Rights Reserved. Business Drivers  What are you trying to do? Provide single sign-on (SSO)? Support dynamic collaboration? Provide a central point of access to distributed services?  Who are the other participants? Services controlled by a single organization? Services provided by trading partners? Parties with whom you have no formal relationship?

Public Information 5 Copyright 2006 Archistry Limited. All Rights Reserved. Additional Considerations  Privacy and consent Will the users use the system? How will their privacy be protected? How will you respond to a right to access request?  Accountability What mechanisms will be used for identity proofing? What mechanisms will ensure non- repudiation of authentication? How will you respond to claims of fraudulent access?

Public Information 6 Copyright 2006 Archistry Limited. All Rights Reserved. Approaches  Don’t federate  Federated identity  Chain of trust  Federated authorization

Public Information 7 Copyright 2006 Archistry Limited. All Rights Reserved. Federated Identities  Leverages the identification/authentication of a trusted member of the federation (e.g. SAML IdP)  May or may not require local accounts at all service providers  Requires out-of-band business agreements between members of the federation  Does nothing more than assert a claim as to the identity of a user or request within a given context

Public Information 8 Copyright 2006 Archistry Limited. All Rights Reserved. Example: US Government E-Authentication Framework

Public Information 9 Copyright 2006 Archistry Limited. All Rights Reserved. Chain of Trust  Each participant responsible for authenticating only the members directly communicating with it  Information integrity must be assured by the information producer  Requires out-of-band business agreements between members of the federation  Each member of the chain is authenticated to the next— any other credential information is opaque  Ensures a sequence of participants can exchange information, but does not directly authenticate (or may not even identify) the original information producer

Public Information 10 Copyright 2006 Archistry Limited. All Rights Reserved. Example: Irish Government’s Reach Project

Public Information 11 Copyright 2006 Archistry Limited. All Rights Reserved. Federated Authorization  Federation defines the semantics of a particular set of profile attributes  Service provider association and access control is based on the presence of one or more attributes  Can be used in conjunction with federated identities or without them for dynamic collaboration  Still requires out-of-band business agreements between members of the federation  Can be used for more flexible and dynamic collaborations, but attribute negotiation may have privacy implications

Public Information 12 Copyright 2006 Archistry Limited. All Rights Reserved. Example: EU Driving License Regulations

Public Information 13 Copyright 2006 Archistry Limited. All Rights Reserved. Technical Considerations  How will the business agreements be managed electronically (Proprietary XML, SAML, XACML, WS-Policy or something else)?  Are the services provided asynchronously or synchronously?  What is the temporal coupling between the services?  Are the services provided to interactive users or automated agents?  How much information is necessary to identify the user to the local service?  Will the local services also support authentication and management of their own user identities?  Which is most important: the identity of the principal making the request or the identity of the principal to which the request refers?  Who (or what) is actually making the request?

Public Information 14 Copyright 2006 Archistry Limited. All Rights Reserved. References  US E-Government Authentication Framework and Programs, IT Professional, May/June 2003, /03/f3toc.xml&DOI= /MITP /03/f3toc.xml&DOI= /MITP  Technical Approach for the Authentication Service Component, Version 1.0.0, GSA (2004),  SAML V2.0 Technical Overview, Working Draft 10, open.org/committees/download.php/20645/sstc-saml-tech-overview-2%200-draft-10.pdfhttp:// open.org/committees/download.php/20645/sstc-saml-tech-overview-2%200-draft-10.pdf  Liberty ID-WSF Web Services Framework Overview, Version 2.0,  Access Control Management in a Distributed Environment Supporting Dynamic Collaboration, Shafiq, B. et al (2005),  Implementing a Federated Architecture to Support Supply Chains, Chadha, B. (2003),  A Distributed Trust Model, Abdul-Rahman, A., S. Hailes (1997),  Access Control in Federated Systems, De Capitani di Vimercati, S. and Samarati, P. (1996),

Public Information 15 Copyright 2006 Archistry Limited. All Rights Reserved. Turning innovation into business value TM Archistry Limited 33 Pearse Street Suite 115 Dublin 2, Ireland Phone Fax