The ICAR Federated Identity Model Massimiliano Pianciamore, CEFRIEL Francesco Meschia, CSI-Piemonte [email protected] [email protected] OASIS eGovernment Workshop on Electronic Identity & Citizen-Centric Administration Santa Clara - May 1st, 2008
Dec 18, 2015
The ICAR Federated Identity Model
Massimiliano Pianciamore, CEFRIELFrancesco Meschia, [email protected]@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)
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
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)