Antecedentes y contexto
Por defecto, todas las cuentas de SAP Cloud Platform vienen conectadas al Servicio de Identidad de SAP en el Proveedor de Identidad. Las identidades de las cuentas de usuarios S, así como las cuentas SCN (usuarios P), son gestionadas por el Servicio de Identidad de SAP. Aunque este es un excelente punto de partida para clientes y socios, es evidente que eventualmente querrán usar Proveedores de Identidad que hayan sido configurados nativamente en su organización, por ejemplo, Azure Active Directory / Okta / etc. Muchos clientes también utilizan el propio Servicio de Autenticación de Identidad de SAP (IAS) como Proveedor de Identidad directamente o incluso utilizan IAS como un proxy a sus almacenes de usuarios corporativos reales.
En esta publicación de blog, configuraremos IAS como un Proveedor de Identidad personalizado para configurar roles para acceder a las capacidades de Integration Suite.
Configuraciones en el Proveedor de Identidad
Configurar un Proveedor de Identidad para suministrar identidad a aplicaciones en una subcuenta es básicamente un proceso de dos pasos para configurar una confianza mutua a través de un intercambio de artefactos de metadatos SAML. Como primer paso, tomemos los metadatos SAML de la Subcuenta donde estamos alojados.
La sección 'Configuración de Confianza' tiene un botón para descargar los Metadatos SAML. Haz clic en este botón y guarda localmente la representación XML del archivo de metadatos.
Ahora, ve a la página de Administración de tu inquilino de IAS para configurar el artefacto que acabamos de descargar. La sección 'Aplicaciones' nos permite configurar diferentes ajustes de Aplicación (identidad).
Llamemos a nuestra Aplicación 'Aplicación de Integration Suite'.
Las 3 secciones importantes que necesitan ser configuradas aquí son: a) Configuraciones para configurar el Proveedor de Servicios SAML (SAP Cloud Platform) b) Identificador de Nombre de Sujeto y c) mapeo de las Afirmaciones que deben estar disponibles en el Proveedor de Servicios.
Para la primera parte, carga los metadatos SAML previamente descargados en el primer paso.
Para la segunda parte, especifica que el correo electrónico del usuario debe mapearse al atributo de correo en la Afirmación. Esto es importante porque por defecto XSUAA espera el atributo de correo electrónico como identificador de sujeto.
Para la tercera parte, añade el Atributo de usuario 'Grupos' y asígnalo al Atributo de Afirmación llamado 'Grupos' (distingue entre mayúsculas y minúsculas)
La siguiente configuración en el Proveedor de Identidad sería aprovechar el concepto de 'Grupos' para incluir en la Afirmación SAML y no tener que lidiar con asignaciones individuales de usuarios durante el paso de gestión de roles en Cloud Foundry. Este enfoque es preferido por muchas organizaciones de TI ya que permite un fácil incorporación y desincorporación de usuarios y permisos que llevan a cabo en un solo lugar (es decir, el propio Proveedor de Identidad)
En la sección de Gestión de Usuarios, incorporamos dos usuarios con fines de demostración. Esto se aprovechará en un artículo de blog diferente cuando queramos distinguir entre permisos de administrador y desarrollador externo.
Pedro Pascal
Se unió el 07/03/2018