Differenze

Queste sono le differenze tra la revisione selezionata e la versione attuale della pagina.

--- guide_pubbliche:howto:identity:shibbolethsp_config [2025/01/16 09:51] – [Ruoli] riccardo.cappone@unipr.it
+++ guide_pubbliche:howto:identity:shibbolethsp_config [2025/09/30 11:22] (versione attuale) – [PKCE (Proof Key for Code Exchange)] riccardo.cappone@unipr.it
@@ Linea 75: / Linea 75: @@
 Per tutti gli entityID non riferiti al dominio unipr.it occorre concordare il rilascio degli attributi, che saranno filtrati e rilasciati in maniera puntuale da parte del nostro IdP.
+Logout URL che il service provider può utilizzare per attivare la funzione di SLO
+**https://shibidp.unipr.it/idp/profile/Logout**
 ===== Istruzioni =====
@@ Linea 186: / Linea 187: @@
-===== Flusso autorizzativo adottato dal nostro OP =====
+===== Flusso autorizzativo implicito adottato dal nostro OP =====
+(solo per i casi di necessità di Token Immediati, Senza Chiamate Back-Channel)
 response_type => id_token (implicit flow)
@@ Linea 194: / Linea 197: @@
 {{:guide_pubbliche:howto:identity:response_type_id_token.png?600|}}
+===== Flussi autorizzativo adottati dal nostro OP =====
+   "response_types_supported":[
+      "id_token",
+      "code",
+      "code id_token",
+      "code id_token token"
+   ]
+=== response_type => id_token (implicit flow) ===
+In questa modalità è attivo solamente l'Authorization Endpoint che dopo l'autenticazione rilascerà l'ID Token comprensivo dei claim sottoscritti dagli scope. La durata dell'ID Token è 1h.
+{{:guide_pubbliche:howto:identity:response_type_id_token.png?600|}}
+=== response_type => code (Authorization code flow) ===
+Quando il valore di response_type è code, ma openid non è incluso nel parametro di richiesta scope, la richiesta è semplicemente un Authorization Code Flow come definito nella RFC 6749. D'altra parte, se openid è incluso nel parametro di richiesta scope, viene emesso un ID Token dall'endpoint token in aggiunta a un Access Token.
+{{:guide_pubbliche:howto:identity:code_flow.png?600|}}
+=== response_type => code id_token (Hybrid Flow) ===
+Quando il valore di response_type è code id_token, vengono emessi un codice di autorizzazione e un ID Token dall'endpoint di autorizzazione, e un Access Token e un ID Token vengono emessi dall'endpoint token.
+{{:guide_pubbliche:howto:identity:code_id_token.png?600|}}
+=== response_type => code id_token token (Hybrid Flow) ===
+Quando il valore di response_type è code id_token token, vengono emessi un codice di autorizzazione, un Access Token e un ID Token dall'endpoint di autorizzazione, e un Access Token e un ID Token vengono emessi dall'endpoint token.
+{{:guide_pubbliche:howto:identity:code_id_token_token.png?600|}}
+===== PKCE (Proof Key for Code Exchange) =====
+<WRAP center round tip 60%>
+Il Codice di Autorizzazione con PKCE (Proof Key for Code Exchange) è oggi lo standard di sicurezza raccomandato per l'autenticazione OpenID Connect (e l'autorizzazione OAuth 2.0), in particolare per i client pubblici (come le Single Page Application, SPA, o le app mobili native).
+</WRAP>
+Il flusso del Codice di Autorizzazione è intrinsecamente più sicuro del Flusso Implicito perché gestisce lo scambio dei token sul back-channel (server-to-server), lontano dal browser, rendendo i token inaccessibili a JavaScript malevolo.
+PKCE aggiunge un ulteriore livello di sicurezza per i client che non possono custodire un Client Secret (i client pubblici), proteggendo dal rischio che un codice di autorizzazione venga intercettato e utilizzato da un attaccante.
 ===== OIDC client di esempio sviluppato in PhP =====
 [[guide_pubbliche:howto:identity:oidc_client|Esempio di OIDC client scritto in PhP]]
@@ Linea 345: / Linea 395: @@
 [[https://shibidp.unipr.it/.well-known/openid-configuration]]
-Questo URI consente di ottenere l informazioni principali contenute nel Metadata dell'OP Server di autenticazione/autorizzazione, come ad esempio l'Authorization Endpoint, il token Endpoint, ?introspection Endpoint, etc.
+Questo URI consente di ottenere l informazioni principali contenute nel Metadata dell'OP Server di autenticazione/autorizzazione, come ad esempio l'Authorization Endpoint, il token Endpoint, l'introspection Endpoint, etc.
 __Specifiche OAuth2 implementate e supportate__:
@@ Linea 364: / Linea 414: @@
   * client_id
   * client_secret
-  * resource indicator (obbligatorio durante la request autorizzativa come parametro)
+  * resource indicator (parametro obbligatorio nella request autorizzativa)
+il parametro resource richiesto dal client, sarà utilizzatto come audience nei token che verranno rilasciati. Questo valore di audience sarà verificabile solamente dal Server della risorsa che avrà il corrispondente client_id (e client_secret) per verificarlo via introspezione.
 Il client deve effettuare la request autorizzativa verso il server di autorizzazione richiedendo obbligatoriamente:
@@ Linea 370: / Linea 423: @@
   * redirect_uri=<da comunicare preventivamente per la registrazione del Metadata sul Server di autorizzazione>
   * scope=openid profile email spid offline_access
+  * resource=<fornito in fase di registrazione del Metadata>
 Il metodo di autenticazione da utilizzare quando il Client si autentica con il Server autorizzativo è client_secret_basic (credenziali vengono inviate nell'intestazione di autorizzazione come una stringa codificata in base64)
@@ Linea 397: / Linea 451: @@
 Esempio response caso token valido:
+{{ :guide_pubbliche:howto:identity:introspection_ok.png?direct&300 |}}
 ===== Utilizzo dell'Auth Code =====
@@ Linea 419: / Linea 473: @@
 {{ :guide_pubbliche:howto:identity:refresh_token_request.png?direct&600 |}}
+{{ :guide_pubbliche:howto:identity:refreeh_aut_code_requests.png?direct&800 |}}