Protección de apps frontales

Si utiliza una aplicación basada en navegador, puede utilizar el flujo Open ID Connect(OIDC) / OAuth 2.0 authorization_grant para autenticar a sus usuarios. Cuando se detecta un usuario no autenticado, se le redirige automáticamente a la página de autenticación. Cuando finaliza la autenticación, el navegador se redirige a un punto final implícito de /oidc/callback en el que el adaptador intercepta la solicitud. En este punto, el adaptador obtiene señales del proveedor de identidad y, a continuación, redirige al usuario de nuevo a su URL solicitado originalmente.

Para ver la información de sesión de usuario, incluidas las señales de sesión, puede consultar la cabecera Authorization.

Authorization: Bearer <accessToken> <IDToken>

También puede cerrar la sesión de usuarios autenticados. Cuando un usuario autenticado accede a un punto final protegido con oidc/logout añadido, tal como se muestra en el ejemplo siguiente, se le desconecta.

https://myhost/path/oidc/logout

Si es necesario, se puede utilizar una señal de renovación para adquirir automáticamente nuevas señales de acceso y de identidad sin que el usuario tenga que volver a autenticarse. Si el proveedor de identidad configurado devuelve una señal de renovación, se mantiene en la sesión y se utiliza para recuperar nuevas señales cuando caduca la señal de identidad.

Protección de apps de fondo

El Adaptador puede utilizarse en colaboración con OAuth 2.0 Flujo de portadores JWT para proteger las API de servicios mediante la validación de tokens JWT Bearer. El flujo de autorización de Bearer espera que una solicitud contenga una cabecera de Authorization con una señal de acceso válida y una señal de identidad opcional. La estructura de cabecera esperada es Authorization=Bearer {access_token} [{id_token}]. A los clientes no autenticados se les devuelve un estado de respuesta HTTP 401 con una lista de los ámbitos que son necesarios para obtener la autorización. Si las señales no son válidas o han caducado, la estrategia de API devuelve una respuesta HTTP 401 con un componente de error opcional que dice Www-Authenticate=Bearer scope="{scope}" error="{error}".

Para obtener más información sobre las señales y cómo se utilizan, consulte Información sobre las señales.

Definición de una configuración

En función de si va a proteger aplicaciones frontales o de fondo, cree una configuración de política con una de las opciones siguientes.

• Para aplicaciones frontales: las aplicaciones basadas en navegador que requieren autenticación de usuario se pueden configurar para que utilicen el flujo de autenticación de OIDC/OAuth 2.0. Para definir un CRD de OidcConfig que contenga el cliente utilizado para facilitar el flujo de autenticación con el proveedor de identidad, utilice el ejemplo siguiente como guía.

  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>
  

  Explicación de los componentes del archivo de configuración YAML

  Campo	Tipo	Obligatorio	Descripción
  discoveryUrl	string	Sí	Un punto final conocido que proporciona un documento JSON de información de configuración de OIDC/OAuth 2.0.
  clientId	string	Sí	Un identificador para el cliente que se utiliza para la autenticación.
  clientSecret	string	*No	Un secreto de texto sin formato que se utiliza para autenticar al cliente. Si no se proporciona, debe existir un campo clientSecretRef.
  clientSecretRef	objeto	No	Un secreto de referencia que se utiliza para autenticar al cliente. La referencia se puede utilizar en lugar del campo clientSecret.
  clientSecretRef.name	string	Sí	El nombre del secreto de Kubernetes que contiene el campo clientSecret.
  clientSecretRef.key	string	Sí	El campo dentro del secreto de Kubernetes que contiene el valor de clientSecret.

• Para aplicaciones backend: La especificación OAuth 2.0 Bearer token define un patrón para proteger APIs mediante el uso de JSON Web Tokens(JWTs). Al utilizar la configuración siguiente como ejemplo, defina un CRD JwtConfig que contenga el recurso de clave pública, que se utiliza para validar firmas de señales.

  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
  

Registro de puntos finales de aplicación

Registre los puntos finales de aplicación dentro de un CRD de Policy para validar las solicitudes entrantes y aplicar las reglas de autenticación. Cada Policy se aplica exclusivamente al espacio de nombres de Kubernetes en el que vive el objeto, y puede especificar los servicios, las vías de acceso y los métodos que desea proteger.

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>

Adaptador

Para ver los registros del adaptador, puede utilizar kubectl o acceder al pod desde el pod appidentityandaccessAdapter de la consola de 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

Si el adaptador no parece recibir solicitudes, consulte los registros de Mixer para asegurarse de que se ha conectado correctamente al adaptador.

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