Front-End-Apps schützen

Wenn Sie eine browserbasierte Anwendung verwenden, können Sie den Open ID Connect(OIDC) / OAuth 2.0 authorization_grant Fluss verwenden, um Ihre Benutzer zu authentifizieren. Wenn ein nicht authentifizierter Benutzer erkannt wurde, wird dieser automatisch an die Authentifizierungsseite weitergeleitet. Wenn die Authentifizierung abgeschlossen ist, wird der Browser zu einem impliziten /oidc/callback-Endpunkt umgeleitet, an dem der Adapter die Anfrage abfängt. An diesem Punkt erhält der Adapter Token vom Identity Provider und leitet den Benutzer dann zurück zu seiner ursprünglich angeforderten URL um.

Um die Informationen zur Benutzersitzung einschließlich der Sitzungstoken anzuzeigen, können Sie den Header Authorization anzeigen.

Authorization: Bearer <accessToken> <IDToken>

Sie können ferner authentifizierte Benutzer abmelden. Wenn ein authentifizierter Benutzer auf einen geschützten Endpunkt zugreift und dabei oidc/logout wie im Beispiel dargestellt angehängt hat, wird er abgemeldet.

https://myhost/path/oidc/logout

Bei Bedarf kann ein Aktualisierungstoken verwendet werden, um neuen Zugriff automatisch anzufordern, ohne dass die Benutzer sich erneut authentifizieren müssen. Wenn der konfigurierte Identitätsprovider ein Aktualisierungstoken zurückgibt, wird dieses persistent in der Sitzung gespeichert und verwendet, um neue Token abzurufen, wenn das Identitätstoken abläuft.

Back-End-Apps schützen

Der Adapter kann in Zusammenarbeit mit dem OAuth 2.0 JWT Bearer flow verwendet werden, um Service-APIs durch die Validierung von JWT Bearer-Tokens zu schützen. Der Bearer-Autorisierungsablauf erwartet eine Antwort mit einem Berechtigungsheader, der ein gültiges Zugriffstoken und ein optionales Identitätstoken enthält. Die erwartete Headerstruktur ist Authorization=Bearer {access_token} [{id_token}]. Für nicht authentifizierte Clients wird der Antwortstatus HTTP 401 mit einer Liste von Bereichen zurückgegeben, die erforderlich sind, um die Autorisierung abzurufen. Wenn die Token ungültig oder abgelaufen sind, gibt die API-Strategie die Antwort HTTP 401 mit einer optionalen Fehlerkomponente zurück, die wie folgt lautet: Www-Authenticate=Bearer scope="{scope}" error="{error}".

Weitere Informationen zu Token und deren Verwendung finden Sie in Informationen zu Token.

Eine Konfiguration definieren

Abhängig davon, ob Sie Front-End- oder Back-End-Anwendungen schützen, erstellen Sie eine Richtlinienkonfiguration mit einer der folgenden Optionen.

• Front-End-Anwendungen: Browserbasierte Anwendungen, die eine Benutzerauthentifizierung erfordern, können so konfiguriert werden, dass Sie den Authentifizierungsablauf OIDC / OAuth 2.0 verwenden. Um eine OidcConfig-CRD zu definieren, die den Client enthält, der den Authentifizierungsablauf mit dem Identitätsprovider erleichtert, verwenden Sie folgendes Beispiel als Leitfaden.

  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>
  

  Komponenten der YAML-Konfigurationsdatei erklärt

  Feld	Typ	Erforderlich	Beschreibung
  discoveryUrl	Zeichenfolge	Ja	Ein bekannter Endpunkt, der das JSON-Dokument mit den OIDC/OAuth 2.0-Konfigurationsdaten enthält.
  clientId	Zeichenfolge	Ja	Eine ID für den Client, die für die Authentifizierung verwendet wird.
  clientSecret	Zeichenfolge	*Nein	Ein geheimer Schlüssel in Klartext, der verwendet wird, um den Client zu authentifizieren. Wenn dieser nicht bereitgestellt wird, muss ein clientSecretRef vorhanden sein.
  clientSecretRef	Objekt	Nein	Ein geheimer Referenzschlüssel, der verwendet wird, um den Client zu authentifizieren. Die Referenz kann anstelle von clientSecret verwendet werden.
  clientSecretRef.name	Zeichenfolge	Ja	Der Name des geheimen Kubernetes-Schlüssels, der clientSecret enthält.
  clientSecretRef.key	Zeichenfolge	Ja	Das Feld im geheimen Kubernetes-Schlüssel, das clientSecret enthält.

• Für Backend-Anwendungen: Die Spezifikation OAuth 2.0 Bearer token definiert ein Muster für den Schutz von APIs durch die Verwendung von JSON Web Tokens(JWTs ). Definieren Sie eine JwtConfig CRD, die die öffentliche Schlüsselressource enthält, die für die Überprüfung der Tokensignaturen verwendet wird, indem Sie die folgende Konfiguration als Beispiel verwenden.

  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
  

Anwendungsendpunkte registrieren

Registrieren Sie die Anwendungsendpunkte innerhalb der Policy CRD, um eingehende Anforderung zu überprüfen und Authentifizierungsregeln zu erzwingen. Jede Policy gilt exklusiv für den Kubernetes-Namespace, in dem das Objekt vorhanden ist, und kann die Services, Pfade und Methoden angeben, die Sie schützen möchten.

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>

Adapter

Um die Adapter-Protokolle zu sehen, können Sie kubectl verwenden oder auf den Pod über den appidentityandaccessAdapter-Pod der Kubernetes-Konsole zugreifen.

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

Wenn der Adapter scheinbar keine Anforderungen empfängt, überprüfen Sie die Mixerprotokolle, um sicherzustellen, dass die Verbindung zum Adapter erfolgreich hergestellt wurde.

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