Claim

I claim vengono elaborati prima nel metodo di autenticazione e poi nella registrazione applicativa, dove e possibile decidere quali claim passano allo step successivo ed eseguire trasformazioni e attivita dei claim.

Tutti i confronti tra claim sono sensibili a maiuscole e minuscole.

Il processo dei claim inizia nel metodo di autenticazione quando un utente si autentica. Li e possibile eseguire trasformazioni e attivita dei claim e configurare quali claim devono essere portati avanti allo step successivo. Successivamente il processo dei claim continua nella registrazione applicativa, dove e anche possibile eseguire trasformazioni dei claim e configurare quali claim devono essere emessi verso l'applicazione / API.

In uno scenario Client Credentials Grant, il processo dei claim viene eseguito solo nella registrazione applicativa. Lo stesso vale per le trasformazioni dei claim e per la configurazione di quali claim devono essere emessi verso l'applicazione / API.

Per i valori usati all’interno di FoxIDs, scegliere _local: per un insieme di trasformazioni, _internal: per il flusso di autenticazione corrente comprese le trasformazioni dell’applicazione, oppure _session: per accessi successivi dal browser tramite lo stesso metodo. Questi claim riservati non vengono emessi alle applicazioni. Vedere Claim locali, interni e di sessione, incluso come copiare un valore di sessione in un claim interno per le trasformazioni dell’applicazione.

Metodo di autenticazione

Sia in un metodo di autenticazione OpenID Connect sia SAML 2.0, i claim vengono inoltrati aggiungendoli alla lista Forward claims. Tutti i claim vengono inoltrati se alla lista Forward claims viene aggiunto il wildcard *.

I seguenti claim identificano l'ultimo metodo di autenticazione utilizzato. Vengono inoltrati per impostazione predefinita e possono essere letti nella registrazione applicativa e usati nelle trasformazioni e attività dei claim:

  • auth_method contiene il nome del metodo di autenticazione, che è univoco all'interno dell'ambiente.
  • auth_method_type contiene il tipo di metodo di autenticazione: login, oidc, oauth2, saml2, wsfed, env_link oppure ext_login.
  • auth_profile_method contiene il nome del profilo selezionato per il metodo di autenticazione. Questo claim è incluso quando viene utilizzato un profilo.

Un claim sub e i token ricevuti da un Identity Provider esterno vengono annidati con un simbolo pipe (|) dopo il nome del metodo di autenticazione. Esempi:

  • Un sub esterno con valore afeda2a3-c08b-4bbb-ab77-35138dd2ef2d ottiene il valore annidato the-auth-method|afeda2a3-c08b-4bbb-ab77-35138dd2ef2d
  • Un access token esterno con valore eyJhG.cRwczov...nNjb3B.lIjoi viene aggiunto nel claim access_token con il valore annidato the-auth-method|eyJhG.cRwczov...nNjb3B.lIjoi
  • Se l'OpenID Provider esterno restituisce un refresh token, puo essere inoltrato nel claim refresh_token con il valore annidato the-auth-method|refresh-token-value

Registrazione applicativa

Sia in una registrazione applicativa OpenID Connect, OAuth 2.0 sia SAML 2.0, i claim vengono emessi verso l'applicazione / API aggiungendoli alla lista Issue claims. Tutti i claim vengono emessi verso l'applicazione / API se alla lista Issue claims viene aggiunto il wildcard *.

Una registrazione applicativa OpenID Connect puo distinguere se un claim viene emesso solo nell'access token oppure anche nell'ID token.

Una registrazione applicativa OpenID Connect e OAuth 2.0 puo anche portare avanti i claim tramite uno scope. Questo avviene aggiungendo il claim o i claim alla lista Voluntary claims di uno scope. I claim vengono quindi emessi se l'applicazione client richiede quello scope. Una registrazione applicativa OpenID Connect puo anche distinguere, nei voluntary scope claims, se un claim viene emesso solo nell'access token oppure anche nell'ID token.

Tipi dei valori dei claim

I tipi dei valori dei claim JWT, inclusi oggetti JSON, array, booleani e numeri, vengono conservati quando i claim sono copiati da una trasformazione Map o trasferiti tramite sessioni, Extended UI e grant OAuth. OpenID Connect UserInfo restituisce questi valori con i tipi JSON corrispondenti.

Le trasformazioni che producono nuovo testo, come il mapping regex e la concatenazione, producono valori stringa.

Il mapping dei claim JWT/SAML conserva tipi di valore come booleani e numeri. Nel mapping da JWT a SAML, i valori JSON sono trasferiti come testo in attributi stringa. Nel mapping da SAML a JWT, le stringhe contenenti oggetti o array JSON validi diventano claim JSON.

Identità impersonificate

Un metodo di autenticazione può selezionare un altro utente con una trasformazione Impersonation. Le trasformazioni dell’applicazione ricevono quindi i claim del target e un claim act che identifica l’utente autenticato originale. I claim _impersonate: preparano la selezione nelle trasformazioni del metodo di autenticazione; i claim ausiliari locali mantengono i nomi riservati sotto questo prefisso.

Nei JWT, act è un oggetto JSON, ad esempio {"sub":"original-user"}. Il mapping SAML predefinito è http://schemas.foxids.com/ws/identity/claims/act, modificabile nei mapping dei claim dell’ambiente. Selezionare il claim mappato in Issue claims dell’applicazione SAML, oppure usare *, per emetterne il testo JSON. Quando un attributo SAML contenente questo testo viene rimappato su act, FoxIDs lo emette come oggetto JSON nel JWT.

Claim protetti

FoxIDs gestisce i claim che controllano le sessioni, la validità dei token e l'instradamento tra i metodi di autenticazione. Questi claim protetti non possono essere configurati come output delle trasformazioni dei claim, utilizzati nelle mappature personalizzate dei claim JWT/SAML o associati a valori statici.

I nomi dei claim JWT protetti sono:

  • sid, iss, aud, exp, nbf, iat e auth_time.
  • client_id, azp, scope, nonce, at_hash e c_hash.
  • auth_method, auth_method_type, auth_profile_method e auth_method_issuer.

Anche i corrispondenti tipi di claim SAML per l'indice di sessione, l'istante di autenticazione, l'ID client e il metodo di autenticazione sono protetti. Le mappature dei protocolli integrate in FoxIDs rimangono disponibili.

Le trasformazioni possono leggere i claim protetti e copiarne i valori in claim personalizzati. Un claim protetto può anche essere selezionato in un elenco di claim da inoltrare o emettere senza specificare valori statici.

Le stesse restrizioni si applicano ai claim personalizzati degli utenti interni ed esterni, ai claim iniziali dell'utente del tenant, ai claim dei nodi della struttura di accesso, ai claim di output dell'interfaccia utente dinamica e ai claim statici delle applicazioni e degli scope.

I claim protetti restituiti da una Claims API, da un'API di validazione Extended UI, da una External Login API o da una Directory Connector API vengono scartati. I claim protetti esistenti nel flusso vengono conservati. I claim protetti selezionati possono essere inviati a queste API come input.