SAP IdM y cómo manejar nuestras propias autorizaciones

Hola a todos,

“Los hijos del zapatero siempre van descalzos” 🙂

Esto es algo que puede describir nuestra estructura/concepto de autorización de SAP IdM… no existe tal. Es un caso raro, cuando tenemos que implementar uno y no hay un conector o enfoque estándar para eso.

Con este blog, quiero presentar una posible dirección con la que podemos cubrir este tema.

1º hay que pensar en la parte técnica

Conector SAP IdM para SAP IdM. Conector personalizado con 2 tipos de repositorio: local/remoto, en función de los sistemas que conectaremos (utilice como ejemplo el conector estándar AS JAVA).

Conector IdM: descripción general

• • Conector local SAP IdM (IdM proporcionará acceso por sí mismo)
    • crear una cuenta
      • cuenta de autorización de interfaz de usuario estándar: cuenta estándar creada en función de las autorizaciones de interfaz de usuario
      • Acceso a Eclipse (cuentas de esquema y paquete): cuenta de esquema de IdM, basada en acceso de esquema/paquete de IdM

IdM Crear ejemplo de usuario

• • • borrar cuenta
      • cuenta de autorización de interfaz de usuario estándar
      • Acceso a Eclipse (cuentas de esquema y paquete)
    • asignar acceso
      • Acceso a la interfaz de usuario estándar/personalizado
      • Acceso a Eclipce (acceso a esquemas y paquetes)
    • quitar acceso
      • Acceso a la interfaz de usuario estándar/personalizado
      • Acceso a Eclipce (acceso a esquemas y paquetes)

Nota: para la autorización del esquema/paquete tenga en cuenta que tenemos procedimientos estándar que se puede utilizar para proporcionar el acceso necesario/solicitado.

Nota: las autorizaciones de esquema/paquete serán necesarias solo para unos pocos usuarios autorizados y debe asegurarse de que solo esos se crearán como tales.

• • Conector remoto SAP IdM (OPCIONAL)

IdM proporcionará acceso a un sistema SAP IdM remoto; aquí podemos volvernos locos y un poco por la borda. Dependiendo del nivel de automatización que desee tener, enumeraré algunas opciones:

• • • Uso del conector IdM y LDAP (opción de VDS/área de espera): dependiendo del tiempo que tenga que pasar con este conector, esto es un poco exagerado
    • Conector IdM usando REST (use REST y llame al sistema IdM remoto)
    • El conector IdM se convierte en IPS verdadero y realiza una llamada PROXY al sistema IdM remoto, si desea jugar con las integraciones SCIM/IPS
    • Conector IdM que utiliza una conexión DB al esquema RT: no es una conexión en tiempo real, pero almacena datos en tablas temporales programadas para ejecutarse en los sistemas remotos
    • Conector IdM que usa un despachador remoto (sé que todos pensarán en eso)… pero esto se incluirá en la sección: un poco exagerado y demasiado exótico 🙂

Nota: dependiendo de la forma en que su sistema proporcione acceso a IdM DEV/QAS/PRD, el conector remoto es opcional.

Nota: aquí estoy enumerando posibles direcciones, no todas se usaron en mis implementaciones de la vida real… hágalo lo más simple posible.

• Autorizaciones SAP IdM/UME (este no es parte de este tema del blog)
  • aquí tenemos el conector estándar AS JAVA SAP

2º tenemos que cubrir el concepto de autorización IdM

2.1. Privilegios de SAP IdM

• Acceso estándar SAP IdM – MX_PRIV…. privilegios
• Privilegios de control de acceso personalizados de SAP IdM UI (sin sistema específico)
  • este tipo de privilegios serán similares a los estándar y no serán específicos del sistema para usar el transporte IdM de DEV a QA a PRD
• Paquete de SAP IdM y privilegios de esquema
  • esos privilegios serán específicos del sistema y tendrán los disparadores estándar de IdM para activar los complementos de AssignUserMembershopt/revoleUserMembership
  • Un comentario importante aquí es que para tener acceso al paquete, la cuenta debe crearse dentro del esquema de Eclipse (desarrollador/desarrollador_admin)
  • dependiendo del nivel de separación que desee tener, puede crear sus privilegios de paquete de IdM a nivel de paquete o según el nivel de autorización (espectador/desarrollador/propietario…)
• Privilegios de activación de SAP IdM (asignados a privilegios no específicos del sistema de IdM)
  • esos privilegios serán específicos del sistema y tendrán los disparadores estándar de IdM para activar los complementos de AssignUserMembershopt/revoleUserMembership
  • dependiendo de la forma en que estructure/utilice su entorno de IdM, es posible que no los necesite

2.2. SAP IdM Business Roles: tenga en cuenta cómo desea construir los BR y la relación entre los privilegios específicos del sistema y los que NO son específicos del sistema.

En cada BR relacionado con IdM, debemos tener el privilegio de activación de BR de IdM, de modo que cuando se soliciten autorizaciones de UI, se actualizará el panorama correcto (DEV/QA/PRD…), ya que cuando solicitamos acceso para un sistema IdM remoto, el acceso debe ser aprovisionado de alguna manera.

El 3er paso es la conexión y carga inicial de un sistema IdM

3.1. Conecte el sistema IdM local. Siempre debe comenzar con el sistema local, ya que al final el acceso solicitado para un sistema remoto (en caso de que tenga uno) será tratado como acceso para el local, cuando se trata de eso… nuestro propio escenario de inicio de IdM 🙂

• importar el paquete custom.connector.idm
• crear un repositorio local de IdM
• carga inicial/atributos de creación de cuenta, sistema/solo privilegios
• carga inicial/creación de privilegios de activación personalizados/esquema/paquete/IdM
• cargar cuentas/asignaciones existentes
• activar disparadores del sistema
• activar trabajos diarios programados

3.2. Conectar el sistema IdM remoto (OPCIONAL)

• importar el paquete custom.connector.idm
• crear un repositorio remoto de IdM
• carga inicial/atributos de creación de cuenta, sistema/solo privilegios
• carga inicial/creación de privilegios de activación personalizados/esquema/paquete/IdM
• cargar cuentas/asignaciones existentes
• activar disparadores del sistema
• activar trabajos diarios programados

Atentamente,

simona lincheva