Electronic Identity

Question 1

Delegated authentication generalities

Answer 1

Good solution in a closed environment in which there is a single trusted Authentication Server (AS). It is the entity performing authN pn behalf of the RP and it is trusted by one or more Relying Parties (RPs). It is the only one interacting with the authN client with one among a set of authN protocols. The authN result is provided in the form of a ticket.

In general, when a client that wants to access a service provided by a Service Provider (RP) has to be authenticated, the RP redirects it to the trusted AS which will then provide the result about the performed authentication process in the form of a ticket.

Question 2

Delegated authentication result transmission options, their issues and the needed security

Answer 2

The result, called ticket, can be given to the RP in three different ways:
* push ticket: the ticket is sent to the RP from the AS. This means that the RP has to offer a public andpoint and has to configure its inncoming traffic firewall policies such that the traffic coming from the AS will be accepted. The ticket can be sent through a secure channel and has to be signed by the AS and possibly encrypted for the RP.

• indirect push ticket: the ticket is sent to the client which will forward it to the RP. This way the RP won’t have to offer a public endpoint for the AS cause the ticket will be part of the connection client-RP. The problem here is the possible modification of the ticket due to client actions (modifications and copies), so it has to be encrypted.
• ticket reference with pull ticket: it is the slowest solution cause the client just receives the ticket reference and forward it to the RP; the RP will have to start a connection with the AS (that has to provide a public endpoint) requesting the ticket. If the client modifies the reference then the ticket won’t be retrieved and the client won’t be authenticated.

They differ in term of speed, security and trust and implications on the system, but there is no correct o best solution. It has to be chosen based on the scenario.

Question 3

Problem with tickets in delegated authentication

Answer 3

• the client or a MITM could modify the ticket if not properly protected
• tickets in traffic could be sniffed
• the ticket must be related to just one client without the possibility of being reused (if reusage not taken into account) or being used by some other clients -> ticket replay or ticket reuse
• the ticket has to be authenticated in order to know if it is coming from a trusted AS
• listening service and incoming firewall at RP

Question 4

Federated authentication generalities

Answer 4

It is a good authentication system solution in a context where different AS belong to different security domains and where a RP belonging to a security domain will accept the authN performed by an AS of a different domain. A trust relationship is needed.

The main actors in such a system, apart from the client, are the Identity Provider (Authentication System) and the Service Provider (Relying Party).

Question 5

What is XCAML and why is it used

Answer 5

The Extensible Control Access Markup Language is a markup language which defines a data format to express authorization policies, authZ requests and authZ responses to perform policy-based access control.

Question 6

Entities in a policy based access control (definition and general schema)

Answer 6

• PEP - Policy Enforcement Point: it is the entity that takes care of permitting or denying requests of access to a resource is protected by some access policies. To make such decision it uses the PDP.
• PDP - Policy Decision Point: it is the entity that, based on the informations received by the PEP (request details, subject who made the request, target that it wants to access) and the informations gained through the PIP and the PAP, gives a result about the possibility of access. The PDP uses XCAML: that’s why there is also a context handler to manage requests and responses to and form the PDP, cause the other entities do not use XCAML
• PAP - Policy Access Point: it has access to the policy repository and it is used by the PDP to retrieve the policy needed to evaluate the request
• PIP - Policy Information Point: it is the entity used by the PDP to gain additional informations such as the time and location of the request
• policy repository: it contains the policies related to the system
• subject: entity that wants to access a resource
• resource: target protected by some access policies

Question 7

Where is XCAML used?

Answer 7

policy based access control -> context handler

Question 8

XCAML policy format

Answer 8

• PolicySet: contains one or more Policies
• Policy: made of one or more Rule fields and of one Target field
• Rule: made of Condition (conditions to be applied, for example if a rule has to be applied only the first day of the year) and Effect (permit/deny)
• Target: made of Resource (one or more references to the resources to be protected, URI), Subject (list of the attributes of the subject to which this policy applies; it can also be a list of users), Action (action allowed by the policy)

Question 9

XCAML request format

Answer 9

A <Request> is made of:
* Resource
* Subject
* Action</Request>

Each one of these fields can have one or more <Attribute> made of AttributeID and AttributeValue</Attribute>

Question 10

XCAML response format

Answer 10

A Response has a Result which is made of:
* Decision: Permit/DEny/Indeterminate/NotApplicable
* Status: of the result

Question 11

Generics about SAML, its goals

Answer 11

The Security Access Markup Language is a data format that wants to standardize the way of defining assertions, of requesting an assertition and of responding with an essertion in order to simplify and standardize the interactions in a multidomain distributed system about permissions.

Question 12

SAML use cases

Answer 12

• web browser SSO: the user wnats to access the service of a SP but the authentication is performed by an IdP and the result is passed along using SAML -> good for delegated authentication
• authorization service: good to implement policy-base access control -> PEP and PDP use SAML to exchange infos
• back office transaction: a user has to perform a transaction of behalf of someone else -> authN to IdP + authZ with PEP and PDP

Question 13

What is a SAML assertion and which types do exist; info common to all assertions

Answer 13

An assertion is a declaration of a fact about a subject and made by an issuer.

There are three types of assertion and custom ones can be defined (with the risk of being understandable only in the definition domain). The standard ones are authentication assertion, attribute assertion and authorization assertion.

An assertion can be digitally signed.

All types of assertions have some informations in common:
* assertion ID
* Issuer
* IssuanceTimestamp
* subject: name + security domain in which the name is meaningful
* conditions for which the assertion is valid. SAML client MUST reject assertions of which they do not understand the conditions

Question 14

SAML authentication assertion

Answer 14

An authentication assertion declares that a Subject was authenticated at the time T using the authentication method M.

SAML DOES NOT PERFORM THE AUTHN, IT JUST STATES THE RESULT.

An assertion of this type contains the AuthenticationStatement which is made of
* authenticationTimestamp
* authenticationMethod
* Subject: made of a Name that is meaningful in the SecurityDomain declared

Question 15

SAML attribute assertion

Answer 15

This type of assertion declares that some attributes having some values are related to an authenticated subject.

They are typically obtained from an LDAP query.

The AttributeStatement contains:
* Subject: made of a Name that is meaningful in the SecurityDomain delcared
* List of Attributes in which each Attribute has AttributeName, Attribute namespace and AttributeValue

Question 16

SAML authorization decision assertion

Answer 16

This assertions states that a subject S is authorized to perform the action A on a target T and that the decision was taken based on the evidence E.

The AuthorizationStatement contains:
* Decision (permit/deny)
* Resource (URI)
* Subject

Question 17

SAML producer-consumer model

Answer 17

In a system that uses SAML there are entities that produce assertions and entities that consume them.
Let’s present a generic consumer-producer model:
1. a client wants to access a service but it is stopped by the PEP and redirect to the Authentication Authority which makes the Authentication Assertion
2. This is consumed by the Attribute Authority which, based on the authentication informations produces an Attribute Assertion stating some facts about the authenticated client
3. The Authentication Assertion and the Attribute Assertion can be also consumed by the PDP which, based on the gained infos, produces an Authorization Assertion
4. The PEP actions will depend on it

There could be multiple authorities with the same role, more clients and more consumers of the assertions, assertions can be pulled or pushed.

Question 18

SAML authentication assertion request

Answer 18

The tag that defines a SAML request is samlp with value Request and also a RequestID.

The Request contains an AuthenticationQuery with the Subject tag.

Question 19

What is a SAML binding

Answer 19

SAML Binding refers to the methods used to transfer SAML messages between entities.

Question 20

Possible SAML binding

Answer 20

In the early versions of SAML, SOAP (Simple Object Access Protocol) was used as the transport protocol over HTTP by having a SOAP messages containing (in the SOAP message body) the SAML request or response.

Today the main used methods are:
- HTTP redirect (GET) binding: This method uses HTTP GET requests to pass SAML messages as URL parameters
- HTTP POST binding: This binding sends SAML messages through HTTP POST requests. The SAML message is typically wrapped inside a hidden form field in an HTML form
- HTTP artifact binding: Instead of directly sending a full SAML message, a small artifact (a reference or token) is sent in a redirect. This artifact can then be used to fetch the full SAML message from a back-channel request.

Question 21

What is a SAML profile + examples

Answer 21

A SAML profile is a concrete use case or implementation pattern of SAML. It defines how to combine various SAML assertions, protocols, and bindings to fulfill a specific purpose or use case. A profile is a way of saying “this is how we’ll use SAML to achieve this particular goal.”

For example:
* Web Browser Profile: This profile is specifically designed for Single Sign-On (SSO) in web applications. In this case, the user authenticates with an Identity Provider (IdP) and is then granted access to the Service Provider (SP) without having to re-authenticate, using SAML assertions.
* SOAP Profile: This profile would be used in situations where SAML assertions need to be transmitted within SOAP messages. While it isn’t widely used today, it could be relevant in scenarios that use web services for authentication.

Question 22

SAML: SOAP-over-HTTP binding

Answer 22

The basic idea of this binding is that:

SOAP is used to encapsulate SAML messages and it is a protocol used for sending messages in a structured way.
- HTTP is used as the transport protocol to carry the SOAP messages over the network.
- SAML messages are encapsulated within the SOAP message body.

Question 23

SAML: SOAP profile

Answer 23

simple object access protocol

This profile would be used in situations where SAML assertions need to be transmitted within SOAP messages. While it isn’t widely used today, it could be relevant in scenarios that use web services for authentication.

Question 24

SAML: web browser profiles characteristics

Answer 24

This profile is specifically designed for Single Sign-On (SSO) in web applications. In this case, the user authenticates with an Identity Provider (IdP) and is then granted access to the Service Provider (SP) without having to re-authenticate, using SAML assertions.

Question 25

SAML HTTP redirect binding

Answer 25

This binding allows to SAML requests and responses to be transported over HTTP. The flow is the following:
1. Client: GET request to the SP which redirects it to the IdP by embedding a SAML-authN-request in the redirect
2. The client is redirected to the IdP and automatically performs a GET with the received SAML-authN-request
3. The IdP runs the authN protocol with the client and creates a SAML-authN-response
4. The IdP responds with an HTML form containing hidden fields about the SAML response
5. The client fills the form and, by clicking the submit button, it automatically performs a POST to the SP providing the SAML-authN-response (so it is pushed)
6. The SP checks the result and eventually provides the requested service

Question 26

SAML HTTP artifact binding

Answer 26

This binding allows to SAML requests and responses to be transported over HTTP.
The difference wrt the HTTP redirect binding is that the SAML response is substituted by a reference (and consequences).

The flow is the following:
1. Client: GET request to the SP which redirects it to the IdP by embedding a SAML-authN-request in the redirect
2. The client is redirected to the IdP and automatically performs a GET with the received SAML-authN-request
3. The IdP runs the authN protocol with the client and creates a SAML-authN-response
4. The IdP responds with an HTML form containing the artifact (pointer to the SAML response)
5. The client fills the form and, by clicking the submit button, it automatically performs a POST to the SP providing the artifact
6. The SP pulls the real response from the IdP with an agreed protocol, checks the result and eventually provides the service

Question 27

SAML SSO for Google APPS

Answer 27

Suppose a company whose users want to access google services but that must be authenticated by the company itself.
To implement this system the company will have to provide to google the URL of its own SSO service and the X.509 certificate to verify its signatures. Google will have to provide an Assertion Consuming Service URL to use when sending the assertion about the authN.

This is the flow:
1. the user asks Google for a Google Service
2. Google uses the company SSO URL to redirect the user to the IdP by creating a SAML-authN-request
3. The IdP receives the request, parses it, creates a SAML-authN-response
4. The browser uses the ACS URL to forward the response containing the assertion
5. The ACS consumes the assertion and eventually provides the Google Service to the user

Question 28

What is a federated identity and how can it be implemented?

Answer 28

Federated Identity is a way to allow a user to use the same credentials to access multiple applications or services that belong to different security domains.

SAML can be used to implement Federated Identity.

Question 29

In which context is OpenID-Connect used?

Answer 29

delegated authentication

Question 30

OIDC generics

Answer 30

OpenID-Connect is a delegated authentication system which is based on JSON data format and REST protocols.
Its main actors are:
* User: entity that has to be authenticated
* Client: entity that asks to OIDC to authenticate the user
* OIDC-Provider (IdP): it authenticates the user using three different endpoints: AuthZ Endpoint, Token Endpoint (to verify token validity), UserInfo Endpoint

Question 31

OIDC user authentication and login

Answer 31

1. The user wants to perform login in a web site
2. The OIDC client (SP) will generate the proper AuthN request and then it will redirect the User to the Authorization End Point (AuthZEP). The redirect consists in a GET request whose endpoint ends with /authenticate;
3. The AuthZEP will first validate the AuthN request and, if success, it will create an authentication page. By “validating” we mean that not only the AuthZEP checks the syntactical correctness of the request but it also checks if the Client has a business agreement with the OpenID Provider (OP).
4. The User fills the authentication page with her credentials;
5. The User performs a POST to the /authenticate end point (notice this is the same end point which was used in step 2 to perform the GET request) with her credentials;
6. The AuthZEP verifies the User’s credentials and, if success, it will create an authorization page to ask the User if she expresses consent to transfer her information (e.g., email, username, name and surname, etc…) from the OpenID Provider to the Client;
7. If the User gives consents, she will automatically perform a POST to the /authorise endpoint;
8. The AuthZEP will then generate an AuthN response and the User will be redirected…
9. After the redirect, the User will automatically perform a GET request to the /callback endpoint of the Client, with an authorization statement (AuthZC);
10. The Client will then POST the authorization answer to the /tokens endpoint of the TokenEP
11. The TokenEP verifies if the AuthZ answer is correct or not and, if success, it will return the identity (IDT ) and the account (AccT ) of the User to the Client;
12. The Client verifies the received identity and account;
13. If the original request was also meant to request other User’s attributes (e.g., username, etc…) then an optional step may take place, where the Client performs a GET to the /userinfo endpoint of the UserInfoEP to retrieve the other requested info of the User with account AccT ;
14. The User is now successfully logged into the web site;

Question 32

OIDC security

Answer 32

In OpenID Connect, messages between the Client, Identity Provider (IdP), and Authorization Server are digitally signed to ensure integrity and authenticity. This guarantees that the information hasn’t been tampered with during transmission.

For this to work, the various actors (such as Identity Providers and Clients) need to register their public keys. This is often done via a public key infrastructure (PKI), where each party’s public key is stored and accessible to validate the signature on incoming messages.

All message exchanges (requests and responses) in OIDC are protected by TLS, ensuring that the data is transmitted over an encrypted and secure channel.

Question 33

OIDC claims

Answer 33

Claims in OpenID Connect are pieces of information about the user that are provided by the Identity Provider (IdP). These claims are contained in the ID token issued by the IdP to the client after the user authenticates. Claims are a way to provide structured information about the user.

Profile category
* subject (ID at the issuer)
* name (full), given_name, family_name, middle_name, nickname
* gender
* birthdate
* zoneinfo, locale, profile (URI), picture (URI), website (URI), updated_at (last update at the issuer);

Email category
* email
* email_verified (Boolean): set to true if an OIDC provider has verified that the email is valid (usually this is done by sending a nonce to that email and expecting to receive an email with that same nonce);

Phone category
* phone_number
* phone_number_verified (Boolean): to verify the phone number, a nonce is sent via SMS;

Address category
* address (cannot be verified but only self-declared by the user);

In OpenID Connect, the scope parameter is used to specify what information (or claims) the Client is requesting from the Identity Provider.
For example, requesting openid email phone would ask for ID token claims related to the user’s openid, email, and phone.

You can also request specific claims individually, such as claim=family_name.

Apart for the ones with _verified=TRUE all the others are self-asserted by the user and hence unreliable (!)

Question 34

What is eIDAS and what is its purpose

Answer 34

eIDAS is a European Union regulation that aims to enhance trust and security in electronic transactions across the EU, providing a framework for electronic identification (eID) and electronic trust services. It allows citizens and businesses to use their national electronic identification systems to access public services in any EU member state.

eIDAS Purpose and Principles:
* countries can use their own national identity systems but these systems must be accepted by other EU member states when accessing cross-border services. Countries might implement different technologies for their eIDs but eIDAS ensures they are interoperable.
* eIDAS defines a common legal and technical framework for secure interactions between citizens, companies, and public administrations
* the regulation does not restrict or mandate the use of specific technologies for electronic identification or authentication.

Question 35

Which entities are present in the eIDAS framework?

Answer 35

• Member State (MS): each state of the EU which is part of eIDAS network;
• sending MS: the MS whose eID scheme is used in the authentication process and, as a result, it sends abroad an authenticated ID;
• receiving MS: the MS where the RP (SP that a citizen wants to access) requesting an authN is established
• eIDAS-Connector = a node requesting a cross-border authN
• eIDAS-Service = a node providing cross-border authN;
• eIDAS-Proxy-Service: an eIDAS-Service **operated by the Sending MS **and providing personal identification data (adopted by 99% European countries);
• eIDAS-Middleware-Service: an eIDAS-Service running Middleware provided by the Sending MS, operated by the Receiving MS and providing personal identification data (adopted just by one big European country who didn’t agree with the others)

Question 36

Pan-European eID

Answer 36

The Pan-European eID under the eIDAS regulation enables individuals to use their national electronic identities (eIDs) to access public services across all EU member states, ensuring interoperability and security across borders.

An e-identity is not just authentication but also includes certified attributes (e.g., name, address, birthdate) that are verified by government authorities and trusted for cross-border use.
These attributes must be standardized to accommodate multiple languages, different alphabets, and varying formats (e.g., street addresses, surnames).

Various authentication methods are supported, including passwords, one-time passwords (OTP), smart cards, software certificates, and smartphones.
These credentials must be legally valid and provide a secure way of proving identity according to the standards of the citizen’s home country.

Question 37

eIDAS infrastructure

Answer 37

1. An citizen of country X asks for a service in a country Y;
2. The Y SP asks for authN and wants to use eIDAS. So, it redirects the user to the Y eIDAS Connector, which is the only node in Y which is connected to the rest of Europe through the eIDAS network;
3. The Y eIDAS Connector asks the user which country she’s from and, after receiving the answer, it redirects the user to the X eIDAS Service (if X = Italy it acts as a proxy);
4. The X eIDAS Service asks the user two questions:
   (a) Since the Y SP has asked for the user’s information (e.g., name, surname, email, etc…) does the user consent to provide such information to the foreign SP? (preliminary consent)
   (b) Which e-ID does the user want to use?
   If the user answers to this question too, she will be redirected to the chosen Identity Provider (which is also an Attribute Provider);
5. The chosen Identity Provider:
   (a) will perform the authN procedure, based on the specific technology chosen by the user;
   (b) will ask again for the user’s consent (final consent) to share her information with the foreign SP;
6. If the user gives her final consent, the Identity Provider will generate an authN response that will travel back to the X SP.

Each communication channel (represented in blue in the picture below) uses https. However, data may be left in clear while being transferred from one channel to another. In our example, this could happen at the Italian eIDAS Service, when transferring the authN response to the channel towards the X eIDAS Connector, and at the X eIDAS Connector itself, when passing the authN response to the channel towards the X service provider;

NOTE: the difference between preliminary and final consent is the fact that the former only specifies what kind of attributes will be transmitted if the user gives consent while the latter also specifies the values of the user’s attributes that will be transmitted.

Question 38

eIDAS minimum dataset

Answer 38

The eIDAS regulation defines a minimum data set that must be supported by any eIDAS node for cross-border authentication. This ensures that key identity attributes can be reliably exchanged across EU member states when individuals or organizations access public services.

• 8 attributes for natural person
• 10 attributes for legal person

Question 39

eIDAS security and privacy in the authN process

Answer 39

The strength of an authentication method is determined by how secure the authentication process is. This can range from something simple like a password to something more advanced like smart cards or biometrics.

eIDAS defines the Level of Assurance (LOA) that can be:
* Low LOA: Basic authentication, like using username and password.
* Substantial LOA: More secure authentication, potentially using two-factor authentication (2FA) or smart cards.
* High LOA: Highly secure authentication, which could include the use of biometric data or physical smart cards with asymmetric cryptography.

Even if a high level of cryptographic strength is used, the strength of the identification process also plays a role in determining the overall LOA. If the identification process is weak (e.g., just verifying an email address), the resulting LOA might still be low, even with a strong authentication technique.

Each country willing to join the eIDAS framework has to provide informations about crypto strength of the authN technique used and about the strength of the identification process in order to receive a LOA.

Different services (e.g., government portals, private sector apps) may require a specific LOA to grant access to certain resources. Even if authentication succeeds, if the LOA doesn’t meet the minimum requirements set by the service provider, the authentication attempt may fail.

eIDAS emphasizes privacy and data protection, ensuring that personal data is handled securely, and users have control over what information they share.

When using their eID, users must provide explicit consent for sharing certain attributes with a service provider. This ensures that users are aware of and agree to what personal data will be shared in a given transaction.

Personal data related to the eID is managed end-to-end. This means that personal data is not stored in the eIDAS infrastructure but is instead handled and exchanged in real-time with the user’s consent. This minimizes the risk of data breaches or unauthorized access to sensitive information.

Question 40

SPID

Answer 40

Servizio Pubblico Identità Digitale

SPID architecture is based on three entities:
* IdP: user enrollment, basic attributes and authN
* SP
* Attribute Authority (not yet implemented): provides qualified attributes based on the identity

Each of these identity provides some metadata:
* X.509 certificate
* endpoints
These metadata are signed by the AGID.

It uses SAMLv2 with Web Browser SSO Profile.
It uses both HTTP redirect and HTTP POST.

It offers various authN level:
1. password-based
2. 2FA with password + OTP/app
3. 2FA with asymmetric authN via a secure device

Question 41

eIDAS security requirements

Answer 41

• SAML request (containing no personal data) MUST be digitally signed, but there is no need for encryption;
• SAML responses (containing personal data) MUST be signed and they will contain an EncryptedAssertion with one AuthnStatement (containing the result of the authN) and one AttributeStatement (containing the requested attributes);
• requests may be transmitted via HTTP redirect and HTTP post
• connector metadata contain (among others) encryption certificate and ACS URI;
• TLS version ≥ 1.2, with Qualified (!) web certificates
• TLS compression SHOULD NOT be used and TLS heartbeat neither