Risultati
87 risultati
-
italia
Riferimenti normativi SPID
L'avvio del Sistema SPID, per sua natura e complessità, può richiedere di intervenire su diversi aspetti con specificazioni, chiarimenti, note informative e casi esemplificativi, al fine di dare supporto ad una migliore applicazione e comprensione dei Regolamenti SPID già emanati dall'AgID in conformità con quanto prescritto dall'art.4 del DPCM 24 ottobre 2014. Al fine di raccogliere organicamente tali interventi e attribuirvi un carattere cogente che ne comporti l'obbligo di applicazione da parte degli attori convolti nel Sistema SPID, siano essi pubblici che privati, è stata creata la presente sezione “Avvisi SPID” con l'obiettivo di assicurare un'uniforme interpretazione delle regole, degli aspetti tecnici e di quant'altro necessario per il corretto funzionamento del Sistema nel suo complesso. Le presenti regole tecniche implementano i seguenti avvisi SPID:. Riferimento. Data. LL.GG. OpenID Connect in SPID. LL.GG. OpenID Connect in SPID. 24/11/2021. Avviso n.41. Avviso n.41 - Integrazione LL.GG. OpenID Connect in SPID.pdf. 06/05/2022. Tabella Attributi utente v1.3. Tabella Attributi in SPID - Integrazione LL.GG. OpenID Connect in SPID.pdf. 24/06/2022. Determina SPID OpenID Connect Federation. Regole tecniche per il funzionamento della Federazione SPID OpenID Connect - Integrazione LL.GG. OpenID Connect in SPID.pdf -. 14/09/2022. Linee Guida Attribute Authority SPID. Linee guida recanti le regole tecniche dei gestori di attributi qualificati. 18/07/2022 ...
-
italia
Come contribuire
Per contribuire clicca in alto a destra sulla icona di GitHub, alla voce "Sorgente" e accedi al repository pubblico. Se trovi una inesattezza o desideri risolvere un dubbio o semplicemente notificare qualcosa per migliorare questa documentazione, apri una nuova Issue. A seguito dell'apertura della Issue e dei riscontri ottenuti dalla comunità di Developers italia potrai aprire una nuova Pull Request contenente la modifica o la correzione da te proposta ...
-
italia
Revocation Endpoint
Come definiti per Token endpoint ...
-
italia
Authorization endpoint (Authentication)
In caso di errore, l'OP o il RP rappresentano i messaggi di anomalia relativi agli scambi OpenID Connect, come descritti nelle relative tabelle definite dalle Linee Guida UX SPID. Claim. Descrizione. Supportato da. Errore. Vedi Codici di errori. Descrizione dell'errore. Descrizione più dettagliata dell'errore, finalizzata ad aiutare lo sviluppatore per eventuale debugging. Questo messaggio non è destinato ad essere visualizzato all'utente (a tal fine si faccia riferimento alle Linee Guida UX SPID). state. Parametro obbligatorio solo nel caso di risposta di errore alla Authentication Request e DEVE essere uguale al valore state incluso nella Authentication Request. Il RP DEVE verificare che corrisponda a quello inviato nella Authentication Request. Codici di errore. Errore. Descrizione. Codice HTTP. Supportato da. access_denied. L’OP ha negato l’accesso a causa di credenziali non valide o non adeguate al livello SPID richiesto (RFC 6749#section-4.1.2.1). 302 Found. unauthorized_client. Il client non è autorizzato a richiedere un authorization code (RFC 6749#section-4.1.2.1). 302 Found. invalid_request. La richiesta non è valida a causa della mancanza o della non correttezza di uno o più parametri (RFC 6749#section-4.1.2.1). 302 Found. invalid_scope. Sono stati richiesti degli scope non validi (RFC 6749#section-4.1.2.1). 302 Found. server_error. L’OP ha riscontrato un problema interno (RFC 6749#section-4.1.2.1). 302 Found. temporarily_unavailable. L’OP ha riscontrato un problema interno temporaneo (RFC 6749#section-4.1.2.1). 302 Found. unsupported_response_type. Il response_type richiesto non è supportato (RFC 6749#section-4.1.2.1). 302 Found. login_required. L'OP richiede l'autenticazione da parte dell'utente (OpenID.Core#AuthError). 302 Found. consent_required. L'OP richiede il consenso esplicito da parte dell'utente (OpenID.Core#AuthError). 302 Found. request_uri_not_supported. L'OP non supporta l'uso del parametro request_uri (OpenID.Core#AuthError). 302 Found. registration_not_supported. L'OP non supporta l'uso del parametro registration (OpenID.Core#AuthError). 302 Found. invalid_request_object. Il parametro request contiene un Request Object non valido (OpenID.Core#AuthError). 302 Found. Avvertimento. In caso di URI di reindirizzamento non valido, non corrispondente o mancante, l'OP restituisce 400 Bad Request come codice HTTP ...
-
italia
Considerazioni di Sicurezza
L'interoperabilità tra i partecipanti funziona mediante i Metadata ottenuti dal calcolo e dalla conservazione delle Trust Chain. Questo significa che se un OP al tempo T calcola la Trust Chain per un RP e questo al tempo T+n modifica i propri Metadata, l'OP di conseguenza potrebbe incorrere in problematiche di validazione delle richieste di autorizzazione del RP, fino a quando non avrà aggiornato la Trust Chain relativa a questo. La buona pratica per evitare le interruzioni di servizio relative alle operazioni di OIDC Core è quella di aggiungere le nuove chiavi pubbliche all'interno degli oggetti jwks senza rimuovere i valori preesistenti. Oppure, ad esempio, i nuovi redirect_uri. In questa maniera dopo il limite massimo di durata delle Trust Chain, definito con il claim exp e pubblicato nella Entity Configuration della TA, si ha la certezza che tutti i partecipanti abbiano rinnovato le loro Trust Chain, e sarà possibile agli amministratori della Foglia rimuovere le vecchie definizioni in cima alla lista ...
-
italia
Tabella attributi utente
Si riportano per comodità gli esempi che danno luogo alla composizione di un unico JSON Object da parte di più attributi ed in particolare i claim "place_of_birth", "address", "document_details", $PREFIX/registered_office. Si riportano a titolo di esempio due indirizzi italiani:. Attributo. Esempio codifica OIDC. Indirizzo domicilio fisico CAP domicilio fisico Comune domicilio fisico Provincia domicilio fisico Nazione domicilio fisico. "address": { "street_address":"Via Liszt 21", "postal_code":"00144", "locality":"Roma", "region":"RM", "country_code":"IT" }. Indirizzo domicilio fisico CAP domicilio fisico Comune domicilio fisico Provincia domicilio fisico Nazione domicilio fisico. "address": { "street_address":"S.S. Salaria Km 23,800", "postal_code":"00015", "locality":"Monterotondo", "region":"RM", "country_code":"IT" }. Vi sono casi, come per gli Stati Uniti d'America, dove oltre alla nazione (US) esiste uno Stato. In tali casi lo Stato è indicato nel campo Provincia. Si riporta il seguente esempio:. Attributo. Esempio codifica OIDC. Indirizzo domicilio fisico CAP domicilio fisico Comune domicilio fisico Provincia domicilio fisico Nazione domicilio fisico. "address":{ "street_address":"503,Washington Avenue", "postal_code":"12401", "locality":"Kingston", "region":"New york", "country_code":"US" } ...
-
italia
Logout
Nota. Nel caso sia supportato dall'OP un meccanismo di offline_access tramite Refresh Token, quest'ultimo NON DEVE essere revocato a seguito di un logout ...
-
italia
Flusso di autenticazione
Gli schemi di autenticazioni "Entra con SPID" e "Entra con CIE" implementano il flusso OpenID Connect Authorization Code Flow con l'estensione PKCE (Proof Key for Code Exchange, RFC 7636). Questo flusso restituisce un Authorization Code che può essere utilizzato per ottenere un ID Token e un Access Token e se possibile anche un Refresh Token. L'Authorization Code Flow ottiene l'Authorization Code dall'Authorization Endpoint dell'OpenID Provider e tutti i token sono restituiti dal Token Endpoint. . Segue la descrizione dei passaggi, come da numerazione indicata in figura. Seleziona il pulsante "Entra con SPID" o "Entra con CIE";. Nel caso SPID, seleziona l'OP con cui autenticarsi. Il RP prepara una Richiesta di Autorizzazione con i parametri necessari previsti da PKCE e la invia all'Authorization Endpoint dell'OP. L'OP autentica l'utente mediante l'inserimento delle credenziali e ottiene il consenso per l'accesso agli attributi dell'utente da parte del RP. L'OP reindirizza l'utente all'URL contenuto nel parametro redirect_uri specificato dal RP, passando un Authorization Code nell'Authorization Response. Il RP invia l'Authorization Code ricevuto al Token Endpoint dell'OP. Il Token Endpoint dell'OP rilascia un ID Token, un Access Token e se previsto un Refresh Token. Il RP riceve e valida l'Access Token e l'ID Token. Per chiedere gli attributi che erano stati autorizzati dall'utente al punto 3, invia una richiesta all'UserInfo Endpoint dell'OP utilizzando l'Access Token per l'autenticazione all'interno della intestazione HTTP Authorization. Lo UserInfo Endpoint dell'OP verifica la validità dell'Access Token e rilascia gli attributi richiesti al RP ...
-
italia
Differenze tra SPID e CIE id
Entrambi SPID e CIE id prevedono che il RP effettui una richiesta di revoca dell'Access Token in fase di logout dell'utente. In SPID la revoca di un Access Token implica anche la revoca dell'eventuale Refresh Token ancora attivo ad esso collegato e la scadenza della sessione di Single Sign-On se ancora attiva. In CIE id, invece, la revoca di un Access Token non prevede la revoca del relativo Refresh Token, allo stesso tempo la richiesta di revoca di un Refresh Token determina anche la revoca di tutti i relativi token ancora attivi ...
-
italia
UserInfo Endpoint
Come definiti per Token endpoint ...
-
italia
Entity Statement
Trust Anchors e Intermediari (SA) DEVONO pubblicare una policy relativa ai rispettivi discendenti nell'Entity Statement ad essi riferito. La Metadata Policy si DEVE applicare a cascata su tutti i discendenti. Metadata Policy di un TA per un RP. Di seguito vengono riportati i claim che DEVONO essere considerati nel parametro metadata di tipo openid_realying_party all'interno della policy che il TA stabilisce per un RP suo discendente diretto. Claim. Operazioni / Valori. Supportato da. jwks. Operazioni: value. Valori: DEVE contenere i JWKS del RP relativi alle operazioni di Core. essential = true. grant_types. Operazioni: subset_of, super_set. Valori: DEVE contenere authorization_code e refresh_token. essential = true. id_token_signed_response_alg. Operazioni: one_of. Valori: DEVE contenere uno degli algoritmi definiti nella Sezione Algoritmi Crittografici. essential = true. id_token_encrypted_response_alg. Operazioni: one_of. Valori: DEVE contenere uno degli algoritmi definiti nella Sezione Algoritmi Crittografici. essential = false. id_token_encrypted_response_enc. Operazioni: one_of. Valori: DEVE contenere uno degli algoritmi definiti nella Sezione Algoritmi Crittografici. essential = false. userinfo_signed_response_alg. Operazioni: one_of. Valori: DEVE contenere uno degli algoritmi definiti nella Sezione Algoritmi Crittografici. essential = true. userinfo_encrypted_response_alg. Operazioni: one_of. Valori: DEVE contenere uno degli algoritmi definiti nella Sezione Algoritmi Crittografici. essential = true. userinfo_encrypted_response_enc. Operazioni: one_of. Valori: DEVE contenere uno degli algoritmi definiti nella Sezione Algoritmi Crittografici. essential = true. token_endpoint_auth_method. Operazioni: one_of. Valori: DEVE essere private_key_jwt. essential = true. client_registration_types. Operazioni: subset_of. Valori: DEVE essere automatic. essential = true. redirect_uris. Operazioni:. essential = true. client_id. Operazioni:. essential = true. response_types. Operazioni: value. Valori: DEVE essere code. essential = true. Metadata Policy di un TA per un SA. Di seguito vengono riportati i claim che DEVONO essere considerati nel parametro metadata di tipo openid_relying_party all'interno della policy che il TA stabilisce per un SA. Questa policy DEVE essere applicata a cascata ai metadata dei RP discendenti diretti (aggregati) del SA. Claim. Operazioni / Valori. Supportato da. grant_types. Operazioni: subset_of, superset_of. Valori: DEVE contenere authorization_code e refresh_token. essential = true. id_token_signed_response_alg. Operazioni: one_of. Valori: DEVE contenere uno degli algoritmi definiti nella Sezione Algoritmi Crittografici. essential = true. id_token_encrypted_response_alg. Operazioni: one_of. Valori: DEVE contenere gli algoritmi definiti nella Sezione Algoritmi Crittografici. essential = false. id_token_encrypted_response_enc. Operazioni: one_of. Valori: DEVE contenere uno degli algoritmi definiti nella Sezione Algoritmi Crittografici. essential = false. userinfo_signed_response_alg. Operazioni: one_of. Valori: DEVE contenere uno degli algoritmi definiti nella Sezione Algoritmi Crittografici. essential = true. userinfo_encrypted_response_alg. Operazioni: one_of. Valori: DEVE contenere uno degli algoritmi definiti nella Sezione Algoritmi Crittografici. essential = true. userinfo_encrypted_response_enc. Operazioni: one_of. Valori: DEVE contenere uno degli algoritmi definiti nella Sezione Algoritmi Crittografici. essential = true. token_endpoint_auth_method. Operazioni: one_of. Valori: DEVE essere private_key_jwt. essential = true. client_registration_types. Operazioni: subset_of. Valori: DEVE essere automatic. essential = true. redirect_uris. Operazioni:. essential = true. client_id. Operazioni:. essential = true. response_types. Operazioni: value. Valori: DEVE essere code. essential = true. Metadata Policy di un SA per una RP. Di seguito vengono riportati i claim che DEVONO essere considerati nel parametro metadata di tipo openid_relying_party all'interno della policy che il SA stabilisce per un RP suo discendente diretto (Aggregato). Claim. Operazioni / Valori. Supportato da. jwks. Operazioni: value. Valori: DEVE contenere i JWKS del RP relativi alle operazioni di Core. essential = true. Metadata Policy di un TA per un OP. Di seguito vengono riportati i claim che DEVONO essere considerati nel parametro metadata di tipo openid_provider all'interno della policy che il TA stabilisce per un RP suo discendente diretto. Claim. Operazioni / Valori. Supportato da. jwks. Operazioni: value. Valori: DEVE contenere i JWKS del OP relativi alle operazioni di Core. essential = true. revocation_endpoint_auth_methods_supported. Operazioni: subset_of. Valori: DEVE essere private_key_jwt. essential = true. code_challenge_methods_supported. Operazioni: subset_of. Valori: DEVE essere S256. essential = true. scopes_supported. Operazioni: subset_of, superset_of. Valori: DEVE contenere openid, offline_access. Per CIE id PUÒ contenere anche profile, email. essential = true. response_types_supported. Operazioni: subset_of. Valori: DEVE essere code. essential = true. response_modes_supported. Operazioni: subset_of, superset_of. Valori: DEVE contenere form_post, query. essential = true. grant_types_supported. Operazioni: subset_of, superset_of. Valori: DEVE contenere refresh_token, authorization_code. essential = true. acr_values_supported. Operazioni: subset_of, superset_of. Valori: DEVE contenere. https://www.spid.gov.it/SpidL1,. https://www.spid.gov.it/SpidL2,. https://www.spid.gov.it/SpidL3. essential = true. subject_types_supported. Operazioni: subset_of. Valori: DEVE essere pairwise. essential = true. id_token_signing_alg_values_supported. Operazioni: subset_of, superset_of. Valori: DEVE contenere gli algoritmi definiti nella Sezione Algoritmi Crittografici. essential = true. id_token_encryption_alg_values_supported. Operazioni: subset_of, superset_of. Valori: DEVE contenere gli algoritmi definiti nella Sezione Algoritmi Crittografici. essential = true. id_token_encryption_enc_values_supported. Operazioni: subset_of, superset_of. Valori: DEVE contenere gli algoritmi definiti nella Sezione Algoritmi Crittografici. essential = true. userinfo_signing_alg_values_supported. Operazioni: subset_of, superset_of. Valori: DEVE contenere gli algoritmi definiti nella Sezione Algoritmi Crittografici. essential = true. userinfo_encryption_alg_values_supported. Operazioni: subset_of, superset_of. Valori: DEVE contenere gli algoritmi definiti nella Sezione Algoritmi Crittografici. essential = true. userinfo_encryption_enc_values_supported. Operazioni: subset_of, superset_of. Valori: DEVE contenere gli algoritmi definiti nella Sezione Algoritmi Crittografici. essential = true. token_endpoint_auth_methods_supported. Operazioni: subset_of. Valori: DEVE essere private_key_jwt. essential = true. token_endpoint_auth_signing_alg_values_supported. Operazioni: subset_of, superset_of. Valori: DEVE contenere gli algoritmi definiti nella Sezione Algoritmi Crittografici. essential = true. claims_parameter_supported. Operazioni: value. Valori: DEVE essere true. essential = true. request_parameter_supported. Operazioni: value. Valori: DEVE essere true. essential = true. authorization_response_iss_parameter_supported. Operazioni: value. Valori: DEVE essere true. essential = true. client_registration_types_supported. Operazioni: subset_of. Valori: DEVE essere automatic. essential = true. request_authentication_methods_supported. Operazioni: value. Valori: DEVE essere request_object. essential = true. request_authentication_signing_alg_values_supported. Operazioni: subset_of, superset_of. Valori: DEVE contenere gli algoritmi definiti nella Sezione Algoritmi Crittografici. essential = true. request_object_signing_alg_values_supported. Operazioni: subset_of, superset_of. Valori: DEVE contenere gli algoritmi definiti nella Sezione Algoritmi Crittografici. essential = true. issuer. Operazioni:. essential = true. authorization_endpoint. Operazioni:. essential = true. token_endpoint. Operazioni:. essential = true. userinfo_endpoint. Operazioni:. essential = true. introspection_endpoint. Operazioni:. essential = true. revocation_endpoint. Operazioni:. essential = true. Vedi anche. Esempi non normativi di Metadata Policy ...
-
italia
Entity Configuration
Gli EC di un TA, in aggiunta ai claim comuni a tutti i partecipanti, contengono anche i seguenti:. Claim. Descrizione. Supportato da. constraints. JSON Object che descrive un insieme di vincoli della Trust Chain e che DEVE contenere l'attributo max_path_length. Rappresenta il numero massimo di SA tra una Foglia e il TA. PUÒ anche contenere il claim allowed_leaf_entity_types, che restringe i tipi di Entità riconoscobili come suoi discendenti. trust_mark_issuers. JSON Array che indica quali autorità sono considerate attendibili nella Federazione per l'emissione di specifici TM, questi assegnati mediante il proprio identificativo univoco. Vedi anche. Esempio di EC di un TA ...