Truco 49. Autorizaciones desde el Modulo de Organizacion. Roles de usuario con PFCG(I).


En nuestro dos próximos trucos volvemos al modulo Basis para hablar de una funcionalidad no demasiado conocida pero que puede ser muy útil si queremos utilizar el modulo de Organización para construir la estructura de puestos de trabajo de nuestra organización (desde el punto de vista de RRHH o también desde el punto de vista de uso o funciones en Sap). Cada unidad organizativa y/o puesto de trabajo tendrá asociadas las diferentes autorizaciones en el sistema, de forma que cuando un empleado/usuario sea asignado en los diferentes puestos/roles en el arbol organizativo, automáticamente en su perfil de usuario Sap se asignarán todas las autorizaciones vinculadas para que pueda desempeñar las funciones previstas.

De esta forma se realiza una gestión de las autorizaciones mucho más ordenada. Utilizando el arból organizativo de las transacciones del modulo de organización (PPOMW/PPOSW), podemos ver de forma visual nuestra estructura y quién esta asignado en cada lugar (asi como los roles de autorización asignados). Como os digo, puede ser una funcionalidad muy interesante para poner un poco de “orden” en el laberinto en el que se suele convertir la gestión de autorizaciones en Sap conforme los proyectos van evolucionando.ppome1

Antes de entrar en profundidad en el módulo de organización y ver la forma de configurarlo para utilizarlo desde la visión de la gestión de autorizaciones (no desde el punto de vista de RRHH u organigramas, aunque podrian ser compartidos), vamos a hacer un repaso a los aspectos mas importantes de las autorizaciones en Sap. El control de autorizaciones es un concepto transversal en Sap (afecta a todos los módulos) y es fundamental su buena definición para evitar que los usuarios tengan acceso a funciones o tareas para las que no deberían de estar autorizadas por sus funciones en la empresa (en especial a determinados tipo de operaciones o informes).

Objeto de autorización.

Las autorizaciones en Sap se basan en dos unidades básicas de gestión: el campo de autorización y el objeto de autorización.

Con los campos de autorización definimos tecnicamente la longitud de los campos de autorización (dominio), así como los valores posibles que se van a poder indicar en ellos cuando los utilicemos en las definición de nuestras autorizaciones. Por ejemplo, para el control de acceso a transacciones se utiliza el campo TCODE, que tiene el dominio tcode que permite utilizar valores en el campo de longitud 20 (suficiente para cualquiera de las transacciones definidas en Sap).pfcg_campo

En otras autorizaciones debemos de indicar que tipo de actividad esta permitida o no para el usuario. Para este caso, tendremos por ejemplo el campo de autorizacion ACTVT que utiliza el dominio ACTIV_AUTH, asociado a una tabla de valores que indicarán los diferentes actividades que podemos hacer, por ejemplo, en el mantenimiento de datos maestros de articulos, clientes, proveedores, etc (Añadir, Modificar, Borrar, Visualizar modificaciones, etc).pfcg_campo2

Los campos de autorización se definen en la transacción SU20. Sap dispone de campos de autorización suficientes para crear nuestros propios objetos de autorización (aunque es posible si fuera necesaria alguna personalización especifica), crear nuestros propios campos de autorización.

El objeto de autorización es el nivel superior dentro de la gestión de autorizaciones y el objeto básico con el que trabajaremos. Básicamente, un objeto de autorizacion en una etiqueta (nombre técnico) y un conjunto de campos de autorización asociados (de los vistos anteriormente). Los objetos de autorización se mantienen en la transacción SU21, estando clasificados de forma estandar por los diferentes módulos y componentes de Sap. También podremos crear nuestros propios objetos de autorización insertandolos en una clase Z (las clases se crean desde la transacción SU03).pfcg_objeto

La asignación de autorizaciones se realiza utilizando los objetos de autorización, asignando a cada campo una serie de valores, que indican las operaciones permitidas dentro del ambito del objeto de autorización. En el ejemplo de la imagen, podemos ver como el objeto de autorización esta siendo utilizando en un rol de autorizaciones y como se le asignan determinados valores que luego serán los que tenga el usuario al que este rol sea asignado.pfcg_objeto2

Dentro de la programación de las aplicaciones SAP, con la sentencia “AUTHORITY-CHECK” verificaremos que el usuario dispone de la autorización correspondiente y le dejaremos continuar o no con la acción a realizar (en caso de informes podremos estar restringiendo también la información a mostrar). En el estandar Sap lo hace de forma automática, aunque este procedimiento lo podremos incluir también en nuestros desarrollos Z.

* Verificacion de autorizacion para crear pedidos de venta
                       AUTHORITY-CHECK OBJECT ‘V_VBAK_AAT’
                                ID ‘AUART’ FIELD VBAK-AUART
                                ID ‘ACTVT’ FIELD ’01’.
                       IF SY-SUBRC ne 0.
                          message e008(ZSISTEMAS) with ‘SIN AUTORIZACION PARA CLASE DOC’.
                       ENDIF.

Como podeís ver, al final se acaba chequeando cada objeto de autorización concreto y los valores de este. Si el usuario tiene asignada la autorización requerida, puede llevar a cabo la acción. En caso contrario, se genera un mensaje de error o simplemente no tiene acceso a la visualización de los objetos involucrados.

Hay objetos de autorización para casi todo en Sap, desde el acceso a ejecutar transacciones que veiamos antes (TCODE), objetos para modificar datos maestros en los diferentes ambitos (general, centro, sociedad, organización de ventas, sociedad CO, organización de compras, etc). También hay objetos de autorización para las funciones básicas del sistema. De esta forma, casi cualquier operación sobre el sistema, siempre se podrá permitir o no (con la ausencia de la autorización).

Perfiles de autorización.

En versiones anteriores no existia el concepto de roles y se trabajaba con los perfiles de autorización. Estos no eran mas que un conjunto de objetos de autorización con sus correspondientes valores que se asignaban a los usuarios en la transacción SU01/SU10. En versiones mas recientes se  introdujo un concepto mucho mas potente, el de los roles (aunque realmente por detras siempre siguen estando los perfiles de autorización). Los roles se gestionan desde la transaccion PFGC y tiene un generador automatico de perfiles de autorización que veremos a continuación, que facilitan la utilizacion de los objetos de autorización.

Sino queremos trabajar con los roles, siempre podemos definir los perfiles de autorización con la transacción SU02 (opción que no os recomiendo en absoluto).perfiles

En los perfiles se indican los diferentes objetos de autorizacion que vamos a asignar al usuario y con la autorización, que valores incluidos para los campos de dichos objetos. Finalmente, estos se asignan a los usuarios mediante la transacción SU01 en la pestaña Perfiles.

Roles de usuario simples.

Con la introducción del concepto de Rol Sap dio un respiro a los administradores del sistema y les facilito mucho la vida a la hora de realizar la tediosa configuración de las autorizaciones en Sap.

Los roles se definen con la transacción PFCG y son un nivel superior dentro de la gestión de autorizaciones con funcionalidades añadidas como:

  • Creación de menus de usuario asociados al rol: en el rol se define una estructura de carpetas y las transacciones que se van a poner a disposicion del usuario.pfcg_menu
  • Ademas de incluir en el menú transacciones ya creadas, podemos crear las nuestras propias directamente aquí, enlazando a Programas Abap, Querys, Informes de Report Writer o de Investigación, etc:pfcg_menu2
  • Transferencia de menus al rol desde los menus de ambito Sap, de otros roles, desde ficheros de texto.
  • Traducción de los textos asociados o modificación de estos en el ámbito del menu para indicarles textos mas significativos a los usuarios.

Una vez indicadas las transacciones, reports, etc que se asocian al rol, la transacción PFCG automaticamente nos genera o actualiza el perfil de autorizaciones asociado al rol con los objetos de autorización necesarios. Según cada transacción o report indicado, el sistema nos genera una propuesta de autorizaciones que tendremos que actualizar (habrá que concretar los objetos referentes a las unidades organizativas de los diferentes módulos, clases de actividad permitidas, clases de documentos, etc, etc).pfcg_perfil

Desde la pestaña de autorizaciones podemos acceder a la modificación del perfil de autorizaciones. Aquí podremos ver todos los objetos de autorización asignados, asi como los campos relacionados con cada uno de ellos y los valores asignados. Os recomiendo activar siempre la visualización de los nombre técnicos a través de la opción de menú Utilidades –> Activar nombre técnicos.pfcg_perfil2

Además de la propuesta de objetos de autorización que nos realiza Sap según las transacciones indicadas, podremos incluir manualmente nuestros propios objetos de autorización o bien copiarlos de otros modelos (perfil de autorizaciones, modelo, etc). Es interesante conocer que Sap dispone de un repertorio de Roles y Perfiles de autorización estandar que posiblemente podamos utilizar como módelo para nuestras propias autorizaciones.pfcg_perfil3

IMPORTANTE: una vez concluida la definicion de objetos de autorizacion y sus valores, siempre hay que generar el perfil de autorización para que este sea activo y sus valores aplicables a los usuarios.

El último paso sería la asignación del Rol al usuario, bien desde la misma transacción PFCG en la pestaña Usuario o bien desde el mantenimiento de datos de usuarios (transacciones SU01 / SU10 en la sección Roles).

Una vez asignado el Rol al usuario, las autorizaciones estarán disponibles para el usuario en cuestión y si hemos incluido un arbol de transacciones, estas estaran visibles en el Menu del usuario en Sap.pfcg_perfil4

En el Rol no es obligatorio indicar un menú de transacciones, puede incluir unicamente el perfil de autorización (es decir, incluir unicamente objetos de autorización con sus correspondientes valores asignados).

Roles de usuario compuestos.

Los Roles de autorización compuestos también se mantienen desde la transacción PFCG y consisten en roles que a su vez estan formados por varios roles simples. Son un mecanismo para “agregar” varios roles y facilitar su asignación a los usuarios.pfcg_compuesto1

Cuando vemos como esta el rol asignado en el maestro de usuarios, aparece el rol compuesto (es el que podremos asignar o desasignar) y luego en color azul los roles que forman ese rol compuesto (se hace la explosion al asignarlo en el usuario).pfcg_compuesto2

Es un buen mecanismo para “agrupar” autorizaciones y simplificar la gestión de la asignación a los usuarios.

Analisis de autorizaciones y traza.

Para concluir este repaso a nociones básicas de autorizaciones en Sap, os recomiendo una lectura anterior del blog donde hablabamos de como analizar problemas con autorizaciones y como realizar una traza en el sistema para obtener que autorizaciones se verifican realmente: ver entrada aquí. Resumiendo:

  • Transacción SU24: objetos de autorización verificados en cada transacción.
  • Transacción SU53: ultima verificación de autorizaciones erronea realizada en el usuario actual.
  • Transacción SU56: autorizaciones existentes en memoria para el usuario actual (las asignadas en su perfil).
  • Transacción ST01: traza de autorizaciones verificadas  (también la transacción STKONTEXTTRACE). Nos permite hacer una medición de todas las autorizaciones que son verificadas en un determinado usuario, transacción, etc.st01

Las autorizaciones SU53 y SU56 seria conveniente que estuvieran asignadas a todos los usuarios por autorizaciones (o bien permitiendo siempre su ejecución con el parametro de sistema auth/tcodes_not_checked).

Una vez introducidos los conceptos básicos de autorizaciones, en nuestra próxima entrada veremos la forma de gestionar las autorizaciones utilizando el módulo de Organización de Sap, y como asignando los usuarios a las posiciones del Organigrama, podremos derivar la asignación automatica de autorizaciones. Con una herramienta visual podremos de forma jerarquica ver nuestra estructura de usuarios y las posiciones funcionales y roles de autorización que tienen asignados.

Esta entrada fue publicada en Autorizaciones, Sap Basis. Guarda el enlace permanente.

29 respuestas a Truco 49. Autorizaciones desde el Modulo de Organizacion. Roles de usuario con PFCG(I).

  1. Angélica dijo:

    Hola.
    Interesante Nota, ilustrativa y fácil de entender, despeja las dudas que tenemos quienes recién nos sumergimos en el tema de Autorizaciones SAP.
    Estaré a la espera de que publiquen la segunda parte.
    Saludos.

  2. Pingback: Truco 50. Autorizaciones desde el Modulo de Organizacion. PPOCW y PPOMW (y II). | Notas y trucos SAP (Bitacora)

  3. Sandra Da Silva dijo:

    Wow me interesa bastante el tema y agradezco que publiquen tan interesante información. ¡Gracias!

  4. Noemi Huerta dijo:

    Muy claro, tienes fecha para compartir la gestion de autorizaciones a través del modulo de organizacion de sap

  5. Sebastian Monsalve dijo:

    Hola Roberto,
    Me podrías compartir por favor esa información sobre la gestión de autorizaciones a través del módulo de organización de SAP.
    Mi correo es Sebastianmonsam@gmail.com
    Muchas gracias.

  6. JoEn dijo:

    Buenas tardes Roberto, muy interesante la información que suministras, mi trabajo tiene mucha relación con entender estos conceptos. La entyrega PFCG(II) ya la publicaste..?

    Muchos saludos y gracias por tan valioso aporte

    JoEn

  7. Matias dijo:

    Estimado colega, quiero felicitarlo por toda la informacion que comparte en estos blogs, me desempeño como seguridad SAP y en verdad muchas respuestas te las debo a ti. Sigue asi con las ganas que armas cada articulo y como lo detallas de manera tan simple.

    Abrazo!

    • Muchas gracias por tu comentario Matias.

      No te creas, pero no todo el mundo valora y agradece el esfuerzo que supone publicar en el blog y compartir conocimiento…hay muchisimo trabajo detras.

      Saludos.

  8. Josanjp dijo:

    Buenas,

    Tengo una duda existencial:

    ¿Cómo podría controlar/restringir las Unidades Organizativas a nivel de roles compuestos (y no a nivel de roles simples como conozco que se puede hacer)?

    La cuestión es no tener que replicar los roles simples (que compongan el rol compuesto) en cada puesto para poder filtrar por unidades organizatrivas. Por ejemplo: que el puesto jefe contable solo pueda ver informes de su sociedad, el jefe de proyecto solo pueda tener información de su proyecto determinado,…)

    Gracias, saludos

    • Hola Josan:

      Los roles compuestos no son más que una unión de varios roles simples. Lo que podrias hacer es dividir los roles, separando por ejemplo, transacciones de loas unidades organizativas.

      Cuando quieras dar acceso a un usuario a algo, le das acceso a su rol de transacciones y a su rol según las unidades organizativas a las que este autorizado.

      PUedes montar esto con roles compuestos, que incluyan de antenmano los roles a asignar, de la forma que te he indicado.

  9. Victoria dijo:

    Excelente página, ojalá se continúe alimentando para seguir aprendiendo, y que además encontraramos información sobre la VERTICAL DE SALUD.

  10. Manuel dijo:

    Hola, menudo trabajo que hay aquí, es realmente abrumador el nivel de detalle pero sobre todo muy útil. Mi pregunta está relacionada con la PFCG, cómo se puede visualizar la transacción a la izquierda de la descripción de cada una de ellas desde la pestaña Menú dentro de un rol. He visto en los pantallazos que adjuntas que sí figura y otros compañeros la pueden visualizar, no se si es un parámetro de usuario. Muchas gracias por adelantado. Un saludo, gran trabajo!

    • Hola Manuel:

      Prueba eso. En el menú principal, la opción Detalles –> Opciones –> Visualizar nombre técnicos

      Un saludo

      • Manuel dijo:

        Disculpa, lo agrego al hilo de respuesta. Gracias, esa opción ya la había revisado y está activa. Se te ocurre qué otra cosa habría que habilitar?

  11. Manuel dijo:

    Gracias, esa opción ya la había revisado y está activa. Se te ocurre qué otra cosa habría que habilitar?

  12. Liliana dijo:

    Hola. Veo que conoces mucho del tema de autorizaciones. Soy QM y en este momento tengo problema con un cliente. En QM el único nivel de organización que se maneja es el de centro, pero dentro del centro ellos manejan otro concepto que es “Proyecto” y quieren que el acceso sea restringido a nivel de proyecto. El puesto de trabajo funciona en algunas transacciones de ingreso de resultados, pero para las transacciones del sistema de información no funciona. Agradezco si conoces o se te ocurre algo que pueda utilizar para restringir el acceso.

    • Hola Liliana:

      No se puede inventar un nuevo nivel de verificacion de autorizaciones en el estandar. Lo unico que puedes hacer es intentar mirar que cosas (objetos de autorizacion) se verifican en las transacciones de tu modulo. Para ello te propongo:

      1) Transaccion SU21: ver los objetos de autorizacion definidos. Estan organizados por grupos que suelen corresponder a los módulos. Te da una idea de lo que puedes controlar.
      2) Transaccion SU24: objetos que se verifican por transaccion (tienes que mirar los que ponen SI en la columna Propuesta).
      3) Hacer una traza de sistema ejecutando las transacciones y revisando que objetos de autorizacion se verifican. Puedes ver este post antiguo del blog:

      https://saptricks.wordpress.com/2011/06/26/truco-14-analisis-de-autorizaciones-traza/

      Un saludo.

  13. Juan dijo:

    Buenos dias roberto, estoy intentando crear roles masivos en SRM y tengo problemas cuando le asigno nuevos valores en el Nivel Organizativo de la SUIM. El mismo viene vinculado a que los objetos de actualizacion del rol son Z. Ahora lo que no logro es que cuando cambien en la pestaña Nivel Organizativo de la SUIM se refleje en el rol, es decir al mapear en el rol, no se si se entiende. El cambio queda en la pestaña de Nivel Organizativo pero no se mapea al rol. ALguna idea que puede ser.

    Saludos,

    • Hola Juan:

      No entiendo tu pregunta. La transaccion SUIM es el sistema info de usuarios y ahi no veo ninguna pestaña de Nivel organizativo. No se si te has equivocado de transacción, pero no entiendo el problema.

    • Lida dijo:

      También hemos tenido el mismo inconveniente, pero eso sucede es en la PFCG no en la SUIM (creo). Lo que hicimos como alternativa, fue manejar estos permisos con roles simples (no derivados). No encontramos otra opción pero no se si alguien del foro sepa como manejar estos objetos Z que no heredan los valores de los niveles organizativos.

  14. Alberto dijo:

    Hola Roberto, muchas gracias por toda la info. muy explicativa
    Tengo un inconveniente que no sé como resolver. al ajustar valores de un objeto de autorización y generar su perfil, aparte del que yo ajuste aparece nuevamente el perfil estándar de ese objeto.

    ¿Hay forma de impedir que esto suceda y dejar solo el que yo modifiqué?
    actualmente queda el perfil estándar junto con el que yo modifiqué activos, por mas que inactivo el estándar vuelve a aparecer
    Gracias y saludos

  15. Estoy muy interesa do en esto muy buena la explicación

  16. Muy buen aporte, espero que sigas subiendo mas

  17. Joaquin Rojo E. dijo:

    Excelentes Articulos , que nos sirven en el dia a dia para optimizar nuestro trabajo en Seguridad SAP , Te Felicito ..¡¡¡

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s