Identità personalizzata

Puoi utilizzare il tuo provider di identità personalizzata quando esegui l'autenticazione. Il tuo provider di identità può conformarsi a qualsiasi meccanismo di autenticazione alternativo a quelli supportati da IBM Cloud® App ID, inclusi proprietà o legacy.

Panoramica

Utilizzando il tuo provider di identità, puoi creare un flusso di autenticazione personalizzato che utilizza i tuoi protocolli. Hai maggiore controllo, ad esempio sulle informazioni che vuoi condividere o che sono archiviate.

Assicurati di configurare il tuo provider personalizzato prima di aggiungerlo alla tua applicazione.

Quando dovrei utilizzare questo flusso?

Quando App ID non fornisce il supporto diretto per un particolare provider di identità, puoi utilizzare il flusso di identità personalizzato per collegare il protocollo di autenticazione al flusso di autenticazione esistente di App ID. Ad esempio, vuoi utilizzare GitHub o LinkedIn per consentire agli utenti di accedere. Puoi utilizzare l'SDK esistente del provider di identità per facilitare le informazioni sull'autenticazione utente prima di impacchettarle e scambiarle con App ID.

Esistono molti scenari in cui è necessario un flusso di autenticazione differente:

Di proprietà, provider di identità interni
Provider di identità di terze parti
Flussi di autenticazione complessi, che possono includere dei meccanismi multifattore di proprietà

Occasionalmente, un provider legacy potrebbe utilizzare il proprio protocollo di autenticazione personalizzato. Poiché il flusso di identità personalizzato disaccoppia completamente l'autenticazione dall'autorizzazione, puoi utilizzare un qualsiasi meccanismo di autenticazione di tua scelta e fornire le informazioni sull'autenticazione risultanti a App ID. Tutto questo senza esporre le credenziali utente.

Tecnicamente, come funziona questo flusso?

Il flusso di lavoro personalizzato per l'identità è costruito sul tipo di concessione dell'estensione JWT-Bearer, definito in Assertion Framework for OAuth 2.0 Authorization Grants [RFC7521 ]. Per scambiare le informazioni dell'utente per i token App ID, l'architettura di autenticazione crea una relazione di fiducia con App ID utilizzando una coppia di chiavi RSA asimmetriche. Una volta stabilita l'affidabilità, puoi utilizzare il tipo di concessione di connessione JWT per scambiare delle informazioni utente verificate all'interno del JWT firmato con i token App ID.

Come si presenta il flusso?

Come per tutti i flussi di autenticazione, l'identità personalizzata richiede che l'applicazione sia in grado di stabilire un livello di fiducia con App ID per garantire l'integrità delle informazioni utente del provider di identità. L'identità personalizzata utilizza una coppia di chiavi privata e pubblica RSA asimmetriche per stabilire il proprio livello di fiducia. A seconda dei tuoi requisiti dell'architettura, l'identità personalizzata supporta due modelli di attendibilità che differiscono solo nell'ubicazione di archiviazione e nell'utilizzo della chiave privata.

{: caption="di richiesta di autenticazione personalizzataI flussi di richiesta per l'" caption-side="bottom"} personalizzata

Flusso firmato dal fornitore di identità
Provider di identità firmato
Proprio come con i flussi OAuth 2.0 tradizionali, il modello di attendibilità altamente sicuro crea una relazione tra il tuo provider di identità e il server di autorizzazione; in questo caso direttamente App ID. In questo modello, il tuo provider di identità è responsabile dell'archiviazione della chiave privata e della firma delle asserzioni JWT. Quando passate a App ID, queste asserzioni vengono convalidate con la chiave pubblica corrispondente, che garantisce che le informazioni utente dal tuo provider di identità non vengano modificate dolosamente durante il trasporto.

Flusso firmato dell'applicazione
Applicazione firmata
In alternativa, puoi basare il tuo modello di attendibilità sulla relazione tra la tua applicazione e App ID. In questo flusso di lavoro, la tua chiave privata viene archiviata nella tua applicazione lato server. Dopo aver eseguito correttamente l'autenticazione, la tua applicazione è responsabile della conversione della risposta dei provider di identità in un JWT e della sua firma con la propria chiave privata prima che l'applicazione invii il token a App ID. Poiché questo provider di identità non ha alcuna relazione con App ID, questa architettura crea un modello di attendibilità meno sicuro. Sebbene App ID possa fidarsi delle informazioni inviate dall'applicazione lato server, non può essere certo dei dati che erano stati inviati in origine dal provider di identità.

Generazione di un JWT (JSON web token)

È possibile convertire i dati dell'utente verificato in un JWT personalizzato generando un token web JSON. Il token deve essere firmato con la chiave privata che corrisponde alla tua chiave pubblica preconfigurata. Per un elenco di librerie per la firma dei token, consultare il sito https://jwt.io/.

Formato JWT di esempio

{
  // Header
  "alg": "RS256",
  "typ": "JOSE",
  // Payload
  // Required
  "iss": "String", // Should reference your identity provider
  "aud": "String", // Must be the OAuth server URL name
  "exp": "Int",    // Should be a value with a short lifespan
  "sub": "String", // Must be the unique user ID provided by your identity provider

  // Normalized claims (optional)
  "name": "String",
  "email": "String",
  "locale": "String",
  "picture": "String",
  "gender": "String",

  // Custom Scopes to add to access token (optional)
  scope="custom_scope1 custom_scope2"

  // Other custom claims (optional)
  role="admin"
}

Campi JWS
Campo	Descrizione
`iss`	Dovrebbe contenere un riferimento al tuo provider di identità.
`aud`	L'URL del server OAuth. Formato: `https://<region>.appid.cloud.ibm.com/oauth/v4/<tenantID>`.
`exp`	Per quanto tempo è valido il token. Per motivi di sicurezza, dovrebbe avere una durata breve ed essere specifico.
`sub`	L'ID utente univoco fornito dal provider di identità.
Attestazioni normalizzate	Tutte le attestazioni normalizzate vengono fornite nel token di identità restituito nella risposta a questa richiesta. Altre richieste personalizzate possono essere trovate utilizzando l' endpoint `/userinfo`.
Ambito	Per impostazione predefinita, tutti i token App ID contengono un gruppo di ambiti preimpostati. È possibile richiedere ambiti extra effettuando una delle seguenti operazioni: Specificare l'ambito nel campo di applicazione del proprio token JWS. Specifica l'ambito tramite il parametro url-form scopes della richiesta `/token`.

Richiamo dei token App ID

Per creare il bridge tra il tuo provider personalizzato e App ID, devi avere dei token App ID. Per ottenere i token di servizio, scambiare le informazioni dell'utente verificato utilizzando l'endpoint /token.

Post /token
Content-Type: application/x-www-from-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
assertion=<payload>
scope="<spaceSeparatedScopeArray>"

Variabili di richiesta necessarie
Variabile	Descrizione
Content-Type	`applications/x-www-from-urlencoded`
tipo di concessione	`urn:ietf:params:oauth:grant-type:jwt-bearer`
asserzione	Una stringa del payload JWS.
ambito	Un elenco separato da spazi vuoti dei tuoi ambiti personalizzati.