Protezione delle applicazioni front-end

Se si utilizza un'applicazione basata su browser, è possibile utilizzare il flusso Open ID Connect(OIDC) / OAuth 2.0 authorization_grant per autenticare gli utenti. Quando viene rilevato, un utente non autenticato viene reindirizzato automaticamente alla pagina di autenticazione. Quando l'autenticazione viene completata, il browser viene reindirizzato ad un endpoint /oidc/callback implicito dove l'adattatore intercetta la richiesta. A questo punto, l'adattatore ottiene i token dal provider di identità e quindi reindirizza l'utente al suo URL richiesto in origine.

Per visualizzare le informazioni sulla sessione utente, inclusi i token di sessione, puoi consultare l'intestazione Authorization.

Authorization: Bearer <accessToken> <IDToken>

Puoi anche disconnettere gli utenti autenticati. Quando un utente autenticato accede a qualsiasi endpoint protetto con oidc/logout accodato come mostrato nel seguente esempio, viene disconnesso.

https://myhost/path/oidc/logout

Se necessario, può essere utilizzato un token di aggiornamento per automatizzare l'acquisizione di nuovi token di accesso e identità senza che il tuo utente debba rieseguire l'autenticazione. Se il provider di identità configurato restituisce un token di aggiornamento, viene reso persistente nella sessione e utilizzato per richiamare i nuovi token quando il token di identità scade.

Protezione delle applicazioni di backend

L'adattatore può essere utilizzato in collaborazione con OAuth 2.0 Flusso del portatore JWT per proteggere le API dei servizi convalidando i token JWT Bearer. Il flusso di autorizzazione di autenticazione prevede che una richiesta contenga un'intestazione di autorizzazione con un token di accesso valido e un token di identità facoltativo. La struttura di intestazione prevista è Authorization=Bearer {access_token} [{id_token}]. Ai client non autenticati viene restituito uno stato della risposta HTTP 401 con un elenco degli ambiti necessari per ottenere l'autorizzazione. Se i token non sono validi o sono scaduti, la strategia API restituisce una risposta HTTP 401 con un componente di errore facoltativo che indica Www-Authenticate=Bearer scope="{scope}" error="{error}".

Per ulteriori informazioni sui token e sul modo in cui vengono utilizzati, vedi descrizione dei token.

Definizione di una configurazione

A seconda del fatto che tu stia proteggendo applicazioni front-end o backend, crea una configurazione della politica con una delle seguenti opzioni.

• Per le applicazioni front-end: le applicazioni basate sul browser che richiedono l'autenticazione utente possono essere configurate per utilizzare il flusso di autenticazione OIDC / OAuth 2.0. Per definire una CRD OidcConfig che contiene il client utilizzato per facilitare il flusso di autenticazione con il provider di identità, utilizza il seguente esempio come una guida.

  apiVersion: "security.cloud.ibm.com/v1"
  kind: OidcConfig
  metadata:
     name:      oidc-provider-config
     namespace: sample-namespace
  spec:
     discoveryUrl: https://us-south.appid.cloud.ibm.com/oauth/v4/<tenantID>/.well-known/openid-configuration
     clientId:     <clientID>
     clientSecret: <randomlyGeneratedClientSecret>
     clientSecretRef:
           name: <nameOfKubeSecret>
           key: <keyInKubeSecret>
  

  I componenti del file di configurazione YAML spiegati

  Campo	Immettere	Obbligatorio	Descrizione
  discoveryUrl	stringa	Sì	Un endpoint ben noto che fornisce un documento JSON di informazioni sulla configurazione di OIDC/OAuth 2.0.
  clientId	stringa	Sì	Un identificativo per il client che viene utilizzato per l'autenticazione.
  clientSecret	stringa	*No	Un segreto in testo semplice che viene utilizzato per autenticare il client. Se non viene fornito, deve esistere un clientSecretRef.
  clientSecretRef	oggetto	No	Un segreto di riferimento che viene utilizzato per autenticare il client. Il riferimento può essere utilizzato al posto di clientSecret.
  clientSecretRef.name	stringa	Sì	Il nome del segreto Kubernetes che contiene il clientSecret.
  clientSecretRef.key	stringa	Sì	Il campo all'interno di Kubernetes Secret che contiene l'indirizzo clientSecret.

• Per le applicazioni di backend: La specifica OAuth 2.0 Bearer token definisce un modello per proteggere le API utilizzando i JSON Web Token(JWT). Utilizzando la seguente configurazione come esempio, definisci una CRD JwtConfig che contiene la risorsa chiave pubblica, che viene utilizzata per convalidare le firme dei token.

  apiVersion: "security.cloud.ibm.com/v1"
  kind: JwtConfig
  metadata:
     name:      jwt-config
     namespace: sample-app
  spec:
     jwksUrl: https://us-south.appid.cloud.ibm.com/oauth/v4/<tenantID>/publickeys
  

Registrazione degli endpoint dell'applicazione

Registra gli endpoint dell'applicazione all'interno di una CRD Policy per convalidare le richieste in entrata e implementare le regole di autenticazione. Ogni Policy si applica esclusivamente allo spazio dei nomi Kubernetes in cui risiede l'oggetto e può specificare i servizi, i percorsi e i metodi che vuoi proteggere.

apiVersion: "security.cloud.ibm.com/v1"
kind: Policy
metadata:
  name:      samplepolicy
  namespace: sample-app
spec:
  targets:
    -
      serviceName: <svcSampleApp>
      paths:
        - exact: /web/home
          method: ALL
          policies:
            - policyType: oidc
              config: <oidcProviderConfig>
              rules:
                - claim: scope
                  match: ALL
                  source: access_token
                  values:
                    - appid_default
                    - openid
                - claim: amr
                  match: ANY
                  source: id_token
                  values:
                    - cloud_directory
                    - google

        - exact: /web/user
          method: GET
          policies:
            - policyType: oidc
              config: <oidcProviderConfig>
              redirectUri: https://github.com/ibm-cloud-security/app-identity-and-access-Adapter
        - prefix: /
          method: ALL
          policies:
            -
              policyType: jwt
              config: <jwtConfig>

Adattatore

Per visualizzare i log dell'adattatore, puoi utilizzare kubectl oppure accedere al pod appidentityandaccessAdapter dalla console Kubernetes.

alias Adapter_logs="kubectl -n istio-system logs -f $(kubectl -n istio-system get pods -lapp=appidentityandaccessAdapter -o jsonpath='{.items[0].metadata.name}')"
Adapter_logs | jq

Mixer

Se l'adattatore non sembra ricevere richieste, controllate i log del Mixer per assicurarvi che si sia connesso correttamente all'adattatore.

alias mixer_logs="kubectl -n istio-system logs -f $(kubectl -n istio-system get pods -lapp=telemetry -o jsonpath='{.items[0].metadata.name}') -c mixer"
mixer_logs | jq