The ICAR Federated Identity Model

Massimiliano Pianciamore, CEFRIELFrancesco Meschia, CSI-Piemontemassimiliano.pianciamore@cefriel.itfrancesco.meschia@csi.it

OASIS eGovernment Workshop on Electronic Identity & Citizen-Centric AdministrationSanta 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

INF-1 INF-2 INF-3

AP-1

AP-2

AP-3

AP-4

AP-5

AP-6

AP-7

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

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

Service 1

Access to Services: a User-Centric Vision

Req. Attrs:

First Name

Last Nname

Address?

1:Service Request

3: Retrieve Identity

Certification from IdP

ADDRESS

AA1

PROFESSION

AA2

4: Retrieve Address Certification from

AA1

Service 2

Identity,Name,

Last Name

Identity Providers

15

Service 1

Access to Services: a User-Centric Vision

3: Retrieve Identity

Certification from IdP

ADDRESS

AA1

PROFESSION

AA2Retrieve Profession

Certification from AA2

Service 2

Identity,First Name,Last name

Identity Providers

Req. Attrs:

First Name

Last name

Profession?

1:Service Request

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

Codice Fiscale

Residenza

Professione

Qualifica1

Qualifica2

CGN...

Milano

Medico

Codice Fiscale

...

...

CGN...

...

...

AA1

Residenza

Qualifica

...

Milano

Rappres. XYZ

Professione

Qualifica

...

Medico

Avvocato

AA2

AAn

PAsubject

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

AdvantagesLocal Proxy hides federation complexity to SP domainsLocal Proxy hides SP domain complexity to the federationit 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

ICAR Infrastructure Certifying Autorities

(Public Administrations, Professional Associations, ...)

Local and Central Public Administrations

SP1

SPn

SP Domain

Putting it all together: Users, SPs, LP, PAs, AAs and more...

LP PA

ADDRESS

PROFESSION

Attribute Authorities

Identity,First Name,Last name

Identity Providers

PADiscovery

IdPDiscovery

AR

21

ICAR Infrastructure Certifying Autorities

(Public Administrations, Professional Associations, ...)

Local and Central Public Administrations

SP1

SPn

SP Domain

ADDRESS

PROFESSION

Attribute Authorities

Identity,First Name,Last name

Identity Providers

The ICAR Architecture and SAML 2.0

LP PA

PADiscovery

IdPDiscovery

AR

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-band metadata 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)

Questions?

Contacts:massimiliano.pianciamore@cefriel.itfrancesco.meschia@csi.it