The ICAR Federated Identity Model

1. The ICAR Federated Identity Model Massimiliano Pianciamore, CEFRIEL Francesco Meschia, CSI-Piemonte massimiliano.pianciamore@cefriel.it francesco.meschia@csi.it OASIS eGovernment Workshop on Electronic Identity & Citizen-Centric Administration Santa Clara - May 1st, 2008

2. The ICAR Project • The ICAR project stems from the interoperability needs of the 21 Italian administrative regions (17 of which take active part in the project) • The project is co-funded and approved by the National Centre for IT in the Public Sector, CNIPA • The ICAR project is made up of different “tasks” • Some of these tasks are located at application-level (AP-1 through AP-7) • Three more tasks are infrastructure-level tasks (INF-1 through INF-3)

3. ICAR task layering

4. ICAR infrastructural tasks • INF-1 : physical and logical infrastructure enabling interoperability and cooperation between application services • INF-2 : service level monitoring and assurance • INF-3 : authentication and identity management services

5. The INF-3 task • The INF-3 task has just released its deliverables to the participating regions • The INF-3 task enables interoperability of identity management services in e-Gov services spanning different Italian Regions • The INF-3 task is coordinated by the Piedmont Region, in technical partnership with CSI-Piemonte and Cefriel (on behalf of Lombardy Region)

6. INF-3 background • The INF-3 task defined a set of technical guidelines to allow the interoperability of the digital identities of citizens and civil servants • INF-3 does not mandate nor require a refactoring of the internal services of public administration bodies, but rather offers a way to make digital identities “flow” between e-Government services

7. Italian identity background • Every person has a State-issued ID card (plain paper or electronic) stating his personal identity • who he/she is, not what he/she does or can do • Specific roles, qualifications or entitlements (attributes) are asserted by different entities and certified by different documents • e.g. license to drive, educational qualification, professional certification, public administration roles (civil registry officer, employment inspector, etc.) • This is the (real) identity framework we want to mimic in the ICAR digital identity vision

8. INF-3 cornerstones • The key factors required to enable the INF-3 vision are: • different public administration entities acting as a federation of identity providers and attribute providers • separation of duties between identity providers and attribute providers • user-centric management of identities and attributes, with strong emphasis on privacy and trust model • interoperability of digital identities issued by different providers • interoperability and shared semantics of attributes

9. The user profile • Identity providers and attribute providers are separate and largely independent entities… • …but service providers need ‘full’ identities, qualified with attributes, not only ‘intrinsic’ identities • Something must be provided to relate a subject to its attributes • We therefore introduced the concept of “user profile”

10. The user profile • A profile is like a wallet • it keeps a subject’s ID and his entitlements and certifications • A subject may elect to have different profiles • every profile is a different “section” of the subject’s persona • A service provider may not see anything about a subject beyond what is included in the profile • the persona associated with a profile is therefore a “limited liability persona” • the subject is in control of what is made known about his identity

11. ICAR: Architectural model

12. Federated Identity Model in ICAR:Facts and Constraints • No single ‘global’ authority • different authorities can certify different subsets of the attributes related to a certain subject • the same attribute can be certified by different authorities (even with different values) • E.g. ‘role’ or ‘profession’ attribute • Different services may require different subsets of attributes in order to grant access to protected resources • e.g. personal data, professional role qualification, public administration roles (civil registry officer, employment inspector, etc.)

13. Federated Identity Model in ICAR:Facts and Constraints /2 • In general, attribute authorities (AA) do not behave as Identity Providers • i.e. they cannot provide authentication tokens • Attribute retrieval from AAs typically does not involve user interaction • M2M interactions are required • e.g. SOAP requests/responses

14. AA1 Req. Attrs: First Name Last Nname Address AA2 ? Identity, Name, Last Name ADDRESS PROFESSION Identity Providers Access to Services: a User-Centric Vision Service 1 4: Retrieve Address Certification from AA1 1:Service Request 3: Retrieve Identity Certification from IdP Service 2

15. AA1 Req. Attrs: First Name Last name Profession AA2 ? Identity, First Name, Last name ADDRESS PROFESSION Identity Providers Access to Services: a User-Centric Vision Service 1 Retrieve Profession Certification from AA2 3: Retrieve Identity Certification from IdP 1:Service Request Service 2

16. Aggregating user attributes:User Profiles • Accessing a service implies • interaction with trusted Identity Providers in order to obtain an authentication token • retrieval and aggregation of attributes certified by different authorities • Profiles enable attribute aggregation • a profile is a view on the user attribute set • a user profile contains attributes and corresponding certified values • each attribute in a profile is linked to a specific certifying authority • A Profile establishes an ‘Attribute Release Policy’ under the control of the user • when a SP requests an ‘attribute set’, the user selects a profile matching the request and only those attributes are transferred to the requesting party

17. Managing and delivering profiles:Profile Authorities • A Profile Authority enables User Profile Management • users can select and aggregate attributes in profiles • For each attribute the user selects the competent AA • A Profile Authority acts as a ‘User Representative’ towards Attribute Authorities and Identity Providers • receives and collects Authentication and Attribute requests from SPs • gathers user consent • interacts with the user to get explicit authorization for delivering requested attribute sets to requesting SPs • interacts with Identity Providers to obtain authentication tokens • Provides an IdP discovery service to users • interacts with AA to obtain attribute certifications • provides responses (authentication and attribute tokens) to the requesting SPs

18. Managing federation complexity:SP domains, SPs and services • Profile Authorities act as mediators between users and authorities (IdPs and AAs) • Interactions between SPs and the rest of the federation are still very complex • an SP can provide several services • several SPs can form an SP domain (e.g on a regional basis) • It is advisable to have a component acting as a mediator between an SP domain and the rest of the federation

19. Mediating interaction with SPs in the ICAR Federation: The Local Proxy • A ‘Local Proxy’ is a bi-directional gateway between SPs in a SP domain and the rest of the Federation • acts as a Relying Party from the Federation point of view • acts as an Asserting Party for the SPs in the SP domain • Advantages • Local Proxy hides federation complexity to SP domains • Local Proxy hides SP domain complexity to the federation • it could also act as a ‘protocol adapter’ enabling multi-protocol support between SP Domain and the rest of the federation • The GridShib Project uses the same approach with the ‘IdPProxy’ component

20. Certifying Autorities Local and Central Public Administrations ICAR Infrastructure (Public Administrations, Professional Associations, ...) Attribute Authorities SP Domain SP1 Identity, First Name, Last name ADDRESS SPn PROFESSION Identity Providers Putting it all together: Users, SPs, LP, PAs, AAs and more... AR PA Discovery IdP Discovery LP PA

21. Certifying Autorities Local and Central Public Administrations ICAR Infrastructure (Public Administrations, Professional Associations, ...) Attribute Authorities SP Domain SP1 Identity, First Name, Last name ADDRESS SPn PROFESSION Identity Providers The ICAR Architecture and SAML 2.0 AR PA Discovery IdP Discovery LP PA

22. Dynamic Metadata Exchange in the ICAR Federation • Extensive usage of SAML Metadata Exchange protocol in all the interactions between parties • Each entity in the federation describe itself with its own SAML Metadata • Each entity in the federation publishes its own ‘Metadata Provider URL’ in the Authority Registry • No needs for out-of-bandmetadata exchange between entities metadata are dynamically retrieved when needed • Trust establishment in the federation is done by declaring signing certificates in Metadata • Metadata are signed with a Root CA which is trusted by all parties in the federation • Each entity trusts SAML Tokens sent by another entity by dynamically retrieving and processing Metadata of the sender

23. ICAR INF-3: Status and next steps • Architectural components have been just released • Final deployment in the participating regions is planned within march 2009 • Possible evolutions and extensions • OpenID integration • OpenID protocol support in the interactions with IdPs • Cardspace integration • Extending the architecture to support ‘local’ Profile Authorities (i.e. located on user’s PC)

24. Questions? Contacts: massimiliano.pianciamore@cefriel.it francesco.meschia@csi.it