Electronic Identity Flashcards

Question

SAML HTTP redirect binding

Answer 1

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

Answer 2

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

Answer 3

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

Answer 4

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.

Answer 5

delegated authentication

Answer 6

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

Answer 7

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;

Answer 8

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.

Answer 9

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 (!)

Answer 10

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.

Answer 11

* 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)

Answer 12

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.

Answer 13

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.

Answer 14

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

Answer 15

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.

Answer 16

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

Answer 17

* 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

Electronic Identity Flashcards

(41 cards)