SSO GCP | Anjana Data Documentación

Modelo de integración

Autenticación (Oauth2)

Anjana Data se integra mediante circuito estándar Oauth2 para “Web apps” el cual se describe por el fabricante en la siguiente documentación:

https://developers.google.com/identity/protocols/oauth2/web-server

La funcionalidad está directamente embebida en el microservicio de gestión de autenticación Zeus, se habilita y configura mediante el fichero de configuración de dicho microservicio.

Configuración de autenticación

En la propiedad security.authentication se configuran los distintos proveedores de autenticación que se utilizan.

En el caso de GCP es necesario configurar las siguientes propiedades:

YAML

security:
  authentication:
    oidc:
      google:
        # Nombre del proveedor tal y como aparecerá en la página de inicio de sesión
        name: Anjana google
        # URL del proveedor para autorizar a los usuarios del Portal Anjana (usar variables en la URL)
        authorize-url: https://accounts.google.com/o/oauth2/v2/auth?client_id=${security.authentication.oidc.providers.google.client-id}&response_type=code&scope=${security.authentication.oidc.providers.google.scopes}&redirect_uri=${security.authentication.oidc.providers.google.redirect-uri}
        # URL del proveedor para autorizar a los usuarios de Portuno (usar variables en la URL)
        authorize-url-portuno: https://accounts.google.com/o/oauth2/v2/auth?client_id=${security.authentication.oidc.providers.google.client-id}&response_type=code&scope=${security.authentication.oidc.providers.google.scopes}&redirect_uri=${security.authentication.oidc.providers.google.redirect-uri-portuno}
        # URL del proveedor para gestionar la creación del token
        token-url: https://oauth2.googleapis.com/token
        # Alcance de la autenticación del proveedor
        scopes: openid email
        # Identificador del cliente de autenticación en el proveedor
        client-id: <clientId>
        # Secreto del cliente de autenticación en el proveedor
        client-secret: <clientSecret>
        # Método de autenticación del proveedor
        client-authentication-method: BASIC
        # URI a la que el navegador debe redirigir tras un inicio de sesión exitoso con el proveedor en el Portal Anjana 
        redirect-uri: https://<host>/anjana/authorized
        # URI a la que el navegador debe redirigir tras un inicio de sesión exitoso con el proveedor en el portal administrativo (Portuno)
        redirect-uri-portuno: https://<host>/admin/authorized
        # Campo donde se encuentra el nombre de usuario en el proveedor
        username-claim: email
        # Tipo de proveedor
        type: GOOGLE
        # JSON con el contenido de autentificacion requerido, se puede obtener directamente de GCP
        json-content: '
            {
            "type": "service_account",
            "project_id": "AAAAAAAAAA",
            "private_key_id": "******************",
            "private_key": "-----BEGIN PRIVATE KEY----------END PRIVATE KEY-----",
            "client_email": "**************.com",
            "client_id": "*************",
            "auth_uri": "https://accounts.google.com/o/oauth2/auth",
            "token_uri": "https://oauth2.googleapis.com/token",
            "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
            "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/*****.com"
            } '
        # Ruta donde se encuentra el JSON con el contenido de autentificacion, se puede usar en vez de json-content
        json-path: /opt/AAAAA-aaabbbccc.json # absolute path --> /xxxxxx.json
        # Nombre del usuario delegado usado en la autentificación
        delegated: persona@dominio.com
        customer: CCC00

Gobierno activo

De forma general los DSA de Anjana Data serán representados como roles custom y los firmantes de dichos DSA son asociados a dichos roles mediante políticas en cada una de las tecnologías en las cuales adicionalmente se aplicarán condiciones para habilitar el acceso a recursos específicos.

Credenciales requeridas

La credencial puede ser única aglutinando los permisos requeridos por todos los plugins a desplegar, pero se recomienda mantenerla por separado de cara a facilitar la monitorización y auditoría de la actividad ejercida por cada una de las mismas.

Autenticación (Oauth2)

En la actualidad es necesario habilitar acceso tanto en GCP como en Gsuite para poder recuperar la información del usuario y los grupos o roles custom a los que pertenece, para ello es necesario habilitar API específicas de ambos y configurar la delegación de acceso de la cuenta de servicio a usar para que pueda acceder a los scope requeridos de Gsuite.

API’s necesarias

Admin SDK API
Identity and Access Management (IAM) API
Cloud Resource Manager API

Provisión de credencial

OAuth 2.0 Client ID type web application with authorized url pointed to POC installation point (https://<hostname>:<port>/anjana/login and https://<hostname>:<port>/anjana/authorized),default package has configured apache self signed certificate listening con 8443 port. Documentation at https://developers.google.com/identity/protocols/oauth2/web-server

OAuth 2.0 Client type service account with domain delegation and following permissions (DOC https://developers.google.com/admin-sdk/directory/v1/guides/delegation ):
- GCP roles (en la cuenta de servicio a usar en Zeus)
  - Role Viewer
  - Identity Platform Viewer
  - Identity Toolkit Viewer
  - Google Cloud Managed Identities Viewer
  - Functions Viewer
- Permisos a nivel APP (afecta al registrar la nueva aplicación web)
  - Admin SDK API
    - .../auth/admin.directory.user.readonly
    - .../auth/admin.directory.user.alias.readonly
    - ../auth/admin.directory.customer.readonly
    - .../auth/admin.directory.domain.readonly
    - .../auth/admin.directory.group.readonly
    - .../auth/admin.directory.group.member.readonly
    - .../auth/admin.directory.orgunit.readonly
    - .../auth/iam
- Gsuite scopes (afecta en gsuite en el registro de la aplicación web en control de api’s)
  - Openid
    - https://www.googleapis.com/auth/admin.directory.user.readonly
    - https://www.googleapis.com/auth/admin.directory.group.readonly
    - https://www.googleapis.com/auth/admin.directory.group.member.readonly
    - https://www.googleapis.com/auth/admin.directory.domain.readonly
    - https://www.googleapis.com/auth/admin.directory.orgunit.readonly
    - https://www.googleapis.com/auth/cloud-platform
    - https://www.googleapis.com/auth/admin.directory.rolemanagement.readonly

Registrar una web application

Varias API’s están deshabilitadas por defecto y hay que habilitarlas en el siguiente link de la biblioteca de API’s.

Se habilitan las siguientes API:

Una vez habilitados, en la pantalla de permisos, se añaden los siguientes.

Crear ID de cliente OAuth

Se copia y pega y se guarda el JSON de las credenciales.

Crear la cuenta de servicio

Hay que crear una clave de la cuenta de servicio

Se descargará un archivo JSON

Registrar la cuenta de servicio

En Gsuite->seguridad->Control de accesos->Control de API registrar la cuenta de servicio y dar permisos en los scopes necesarios:

Una vez dentro, hay que añadir un API client nuevo

Una vez en el menú, se añade el client ID de la cuenta de servicio que se ha creado anteriormente, y se añaden los siguientes scopes:

Asignación de roles en GCP y Gsuite

En el cloud de Google podemos dar membresías a roles de dos maneras distintas:

Funciones de GCP
Grupo en Gsuite

Funciones en GCP

A diferencia de los grupos de Gsuite, este no genera ninguna cuenta de correo electrónico nuevo y se gestiona a través de GCP.

El procedimiento es el siguiente:

Se crea una función custom con la etapa “Disponibilidad general”, hay que recordar que al valor que se tomará como referencia es el ID y no el nombre

Se asigna la nueva función custom a un usuario en IAM

Grupos en Gsuite

Al crear un nuevo grupo en Gsuite, se genera una nueva cuenta de correo electrónico.

El procedimiento en el caso de los grupos de Gsuite es tan sencillo como crear un grupo y añadir los usuarios que quieras que obtengan esa membresía.

Gobierno activo

El plugin a desplegar el cual realizará la parte de las tareas de gobierno activo que tengan que provisionar roles custom sobre GCP es “Tot plugin GCP IAM”, la credencial requerida está descrita en su documentación asociada. El resto de plugins disponibles de tecnologías integradas con GCP IAM aplicaran políticas de acceso en sus respectivas tecnologías para que dicho rol posea acceso a los recursos cubiertos por el contrato.

El plugin de gobierno activo sobre esta plataforma trabaja exclusivamente creando y asignando roles ya que tienen la suficiente funcionalidad y simplifica la administración al no generar grupos en Gsuite.

Emulación SSO vía Oauth2

El protocolo Oauth2 observa la autenticación transparente en caso de que sea posible, para lo cual solo es necesario redirigir al usuario a https://<host>/provider=<identificador de provider en zeus>, si el usuario ya está logado en dicho provider y las políticas configuradas en dicho provider hacen que no se requiera validar nuevamente la credencial, el usuario será autenticado en Anjana Data de forma totalmente transparente.