Configurazione dell'autenticazione JWT (JSON Web Token) per OpenID Connect

È possibile configurare un server Liberty per accettare un token JSON Web Token (JWT) come token di autenticazione da un proxy di autenticazione attendibile, un client di servizio attendibile o un server di autorizzazione OAuth.

Informazioni su questa attività

La documentazione per l'autenticazione del token web JSON per OpenID Connect è disponibile sul sito web Open Liberty.

Per configurare un server Liberty per accettare un token JWT come token di autenticazione, abilitare la funzione openidConnectClient-1.0 , impostare inboundPropagation="required"e configurare un truststore e SSL. È possibile facoltativamente specificare una configurazione JWT aggiuntiva, come i registri degli utenti, i filtri di autenticazione e la mappatura dei reclami. La configurazione per l'utilizzo di JWT come token di autenticazione è simile a Configurazione di un client OpenID Connect in Liberty.

Qualsiasi parte di fiducia in possesso di un token JWT può utilizzare quel token per accedere alle risorse associate in Liberty. Il server delle risorse Liberty convalida il token JWT e crea il soggetto autenticato dal token JWT. Per essere accettato come token di autenticazione, il token JWT deve contenere iss, sube exp reclami ed essere firmato con l'algoritmo RS256 o HS256 . Nella versione 21.0.0.12 e precedenti, il JWT codificato non è supportato.

Nella versione 22.0.0.1 e successive, è supportato il JWT codificato. Per ulteriori informazioni, vedi il sito web Open Liberty

Il seguente esempio mostra un payload JWT decodificato:

{
	"iss":"https://idp.acme.com:8020/jwt",
	"sub":"marissa@acme.com",
	"exp":1385066178,
	"aud":"https://resource.acme.com/services",
	"iat":1385062578,
	"groupIds": [
	    "group1", "group2"
	 ]
}

Procedura

Aggiungi la funzione openidConnectClient-1.0 Liberty e tutte le altre funzioni necessarie al file server.xml . Al minimo, la funzione openidConnectClient-1.0 richiede la funzione transportSecurity-1.0 . Aggiungere la seguente dichiarazione di elemento all'elemento featureManager nel file server.xml :
```
<feature>openidConnectClient-1.0</feature>
<feature>transportSecurity-1.0</feature>
```
Configurare un elemento openidConnectClient e impostare inboundPropagation="required". Per informazioni su altri attributi openidConnectClient , consultare OpenID Connect Client.
La seguente configurazione del campione presuppone che l'emittente del token JWT supporti un JSON Web Key (JWK) ed è firmato con l'algoritmo RS256 .
```
<openidConnectClient id="RS" inboundPropagation="required"
  jwkEndpointUrl="https://acme.com/jwtserver/jwk" signatureAlgorithm="RS256"
  issuerIdentifier="https://idp.acme.com:8020/jwt" >
</openidConnectClient>
```
Configurare un truststore per includere il certificato endpoint JWK in modo che il server Liberty possa effettuare connessioni SSL all'endpoint JWK. I truststore sono configurati su elementi di keyStore nel file server.xml .
Dopo aver configurato SSL per fare riferimento a questo truststore, è possibile impostare la configurazione SSL come configurazione SSL predefinita del server oppure specificare il truststore ID sull'attributo sslRef dell'elemento openidConnectClient .
Se l'emittente JWT non supporta JWK e JWT viene invece firmato con un certificato X.509 , importare il certificato X.509 dell'emittente nel truststore. Nell'elemento openidConnectClient , specificare il truststore ID sull'attributo trustStoreRef e fare riferimento al certificato sull'attributo trustAliasName .

Se il JWT viene firmato utilizzando una chiave segreta condivisa con l'algoritmo HMAC-SHA256 , definire la chiave segreta condivisa sull'attributo clientSecret .

Per informazioni sui truststore o sui keystore, consultare Abilitazione della comunicazione SSL in Liberty.
Configurare l'attributo issuerIdentifier dell'elemento openidConnectClient per abbinare il claim dell'emittente JWT iss .

Ad esempio, se il token JWT contiene "iss":"https://idp.acme.com:8020/jwt", impostare issuerIdentifier="https://idp.acme.com:8020/jwt".
Opzionale: Configurare un registro utenti.
Per impostazione predefinita, le richieste JWT verificate vengono utilizzate per creare direttamente il soggetto autenticato del chiamante, senza mappare il JWT ad un utente, quindi non è richiesto alcun registro utenti.
Tuttavia, se l'attributo mapIdentityToRegistryUser dell'elemento openidConnectClient è impostato su true, una voce utente per l'identità appropriata deve essere restituita dal server di autorizzazione perché l'autenticazione e l'autorizzazione abbiano esito positivo. Per ulteriori informazioni relative alla configurazione di un registro utenti, consultare Configurazione di un registro utenti in Liberty.
Facoltativo: configurare i filtri di autenticazione come descritto in Filtri di autenticazione.

Se si configura un filtro di autenticazione, fare riferimento al filtro di autenticazione sull'attributo authFilterRef dell'elemento openidConnectClient .

Se l'elemento openidConnectClient non è configurato con un attributo authFilterRef , qualsiasi tentativo di richiesta non autenticata viene autenticato da questo elemento openidConnectClient .
Opzionale: Configurare il server delle risorse Liberty per lavorare con più emittenti JWT o server proxy di autenticazione configurando più elementi openidConnectClient e più filtri di autenticazione.

Ogni elemento openidConnectClient definisce un rapporto di fiducia con un solo emittente JWT o proxy di autenticazione e fa riferimento ad un filtro di autenticazione.
Opzionale: Definisci regole per la mappatura dei crediti JWT ai soggetti di autenticazione.
Il server delle risorse Liberty utilizza i crediti JWT per creare soggetti di autenticazione e si può definire come associare le richieste di JWT al soggetto sui seguenti attributi openidConnectClient elemento:
- userIdentifier
- userUniqueIdentifier
- groupIdentifier
- realmName
- realmIdentifier
Se sia realmName che realmIdentifier sono configurati, realmName ha la precedenza e realmIdentifier viene ignorato.
Se non si definisce la mappatura dei crediti, si applicano le seguenti regole di mappatura predefinite:
- Il claim del soggetto (sub) viene utilizzato come nome principal e nome di sicurezza univoco dell'utente.
- L'asserzione dell'emittente (iss) è il dominio predefinito e utilizzato come dominio soggetto. Se un claim realmName è incluso nel token JWT, il claim realmName viene utilizzato come dominio soggetto invece del claim iss .
Opzionale: Configurare un cookie a firma singola.
Il server Liberty prevede ogni richiesta di fornire un token JWT valido e non crea o utilizza cookie a single sign - on per l'autenticazione. Per creare cookie single sign - on, impostare authnSessionDisabled="false" sull'elemento openidConnectClient .
Opzionale: Configura il server Liberty per ricevere token JWT. Il client web può utilizzare uno dei seguenti metodi per inviare token JWT nelle richieste di risorse al server delle risorse Liberty . Se il token JWT viene inviato nel campo Authorization o in un parametro del corpo codificato, non è richiesta alcuna configurazione server aggiuntiva.

Importante: I Clienti non devono utilizzare più di un metodo in ogni richiesta per trasmettere il token. Se l'attributo headerName è configurato, i token inviati nel campo di intestazione Authorization o in un parametro corpo codificato form vengono ignorati. Se l'attributo headerName non è configurato, l'header Authorization viene ricercato per primo, seguito dal parametro access_token .
- Inviare il token nel campo di intestazione della richiesta Authorization .
```
GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM
```
- Inviare il token nel soggetto di richiesta - corpo come parametro del corpo codificato.
```
POST /resource HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
access_token=mF_9.B5f-4.1JqM
```
- Inviare il token su un campo di intestazione della richiesta personalizzato configurando un nome di intestazione attendibile in Liberty.
  Per configurare il nome dell'intestazione attendibile, impostare headerName="<myJwtHeaderName>" sull'elemento openidConnectClient . Ad esempio, se si imposta headerName="jwt", è possibile inviare il token sul campo di intestazione jwt come mostrato nel seguente esempio:
```
GET /resource HTTP/1.1
Host: server.example.com
jwt: mF_9.B5f-4.1JqM
```
Configurare le udienze JWT.
Per definire un elenco di audience attendibili, configurare l'attributo audiences sull'elemento openidConnectClient .
Un token JWT valido deve soddisfare una delle seguenti condizioni:
- Se l'attributo audiences è configurato, il valore di richiesta del pubblico (aud) deve essere uno degli audience configurati. Per ignorare il controllo del pubblico, impostare audiences a ALL_AUDIENCES.
- Se l'attributo audiences non è configurato, ma il token JWT contiene un claim aud valido URL, il servizio risorse URL deve avere il valore aud come prefisso.
  Ad esempio, il seguente pubblico è valido perché la risorsa URL inizia con il valore di rivendicazione aud :
  
  Richiesta di pubblico: "aud":"https://<server>:<port>/something"
  
  Risorse URL : https://<server>:<port>/something/specific
  Il seguente pubblico non è valido perché la risorsa URL non inizia con il valore della richiesta aud.
  
  Richiesta di pubblico: "aud":"https://<server>:<port>/something/specific"
  
  Risorse URL : https://<server>:<port>/something
Opzionale: mappa programmaticamente JWT token ai soggetti implementando l'interfaccia di programmazione del servizio com.ibm.wsspi.security.oauth.UserCredentialResolver (SPI).

Per informazioni sull'interfaccia, consultare le com.ibm.wsspi.security.oauth.UserCredentialResolver informazioni SPI in Interfacce di programmazione o nella documentazione Java fornita con il prodotto nella directory ${wlp.install.dir}/dev/spi/ibm/ .

Risultati

Hai creato la configurazione minima necessaria per configurare un server Liberty per accettare i token JWT come token di autenticazione.