ICAR-INF3 : inter-regional

identity federation in Italy

Massimiliano Pianciamore, CEFRIEL

Francesco Meschia, CSI-Piemontemassimiliano.pianciamore@cefriel.it

francesco.meschia@csi.it

2nd European Identity Conference

Munich, April 24 2008

2

The ICAR Project

The ICAR project stems from the interoperability

needs of the 20 Italian administrative regions (17

of which take active part in the project)

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 rolled out 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

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-INF3 :

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

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

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

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

PA

Discovery

IdP

Discovery

AR

21

SP1

SPn

SP Domain

ADDRESS

PROFESSION

Attribute

Authorities

Identity,

First Name,

Last name

Identity

Providers

The ICAR Architecture and SAML 2.0

LP PA

PA

Discovery

IdP

Discovery

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 extensionsOpenID 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.it

francesco.meschia@csi.it