La seguridad de SAP es algo compleja, eso creo que ya lo dijimos, pero todas las cosas pueden ser complejas hasta que las entendemos. En este post vamos a tratar de lograr eso.
Algunos temas los empezamos a tratar en posts anteriores, pero no el proceso completo que pasamos a relatar.
1- El usuario ingresa en SAP R/3 y se le permite su acceso
2- Se cargan desde el maestro de usuarios los roles que el usuario posee (tabla AGR_USERS), a partir de los mismos se obtienen los perfiles que tienen las autorizaciones para esos roles (AGR_1016). Aunque es altamente probable que el sistema SAP directamente miré la tabla UST04 (usuarios y perfiles). En caso de perfiles compuestos estos se encuentran definidos en la tabla UST10C. A su vez la relación entre autorización y perfiles está en la UST10S, y por último los valores que se le otorgan a los objetos de autorización se encuentran en la tabla UST12 (probablemente SAP internamente utilice algunas otras tablas o no haga un uso de todas estas, pero es interesante repasarlo porque puede ser de utilidad para ustedes).
3- Esta información recopilada es almacenada en el buffer del usuario, el cual tiene para cada usuario todas las autorizaciones que el mismo posee cuando está logueado en el sistema, esta información puede consultarse para el propio usuario o para otro distinto mediante la transacción SU56 o si se necesita un mayor análisis en la tabla USRBF2 (y vínculos a la tabla UST12).
4- A partir de este momento el usuario ya tiene acceso al sistema y todos sus permisos están cargados. El sistema se encuentra a la espera de una acción por parte del mismo.
5- El usuario decide ejecutar una transacción, por ejemplo la FB02 (modificar documento contable).
6- SAP verifica SIEMPRE que el usuario en su buffer posea el permiso para la transacción. Para esto chequea que el objeto de autorización S_TCODE posea el campo TCD y entre sus valores se encuentre el FB02. Este chequeo no depende de la transacción si no que se ejecuta SIEMPRE que una es llamada.
7- Si se posee el valor FB02 se permite la ejecución del código de la transacción y se procede con el mismo, en caso negativo se rechaza automáticamente la solicitud informándole al usuario.
8- Dependiendo de la transacción a ejecutar, la misma puede chequear como primera instancia (antes de la ejecución del código) que se posea un objeto de autorización con un valor determinado para más de un campo. Este objeto, campos y valores se especifican en la definición de la misma a través de la transacción SE93 o la tabla TSTCA donde también pueden consultarse. Este chequeo actúa igual que el del código de transacción y se realiza previo a la ejecución del programa correspondiente a la transacción. En el caso de la transacción FB02 se chequea el objeto F_BKPF_BUK y la actividad (campo ACTVT) con valor 02 (modificación), el campo Sociedad (BUKRS) en esta instancia, no se verifica ya que el valor de chequeo está en blanco). Cabe destacar que no todas las transacciones realizan este chequeo inicial.
9- A partir de este momento se inicia la ejecución del código.
10- El código ABAP de la transacción se ejecuta hasta que dentro del mismo aparezca la instrucción AUTHORITY_CHECK.
11- A través de esta instrucción el programa verifica que los valores especificados para cada campo en la misma se encuentren en el buffer del usuario que la ejecuta. En caso de tenerlos se permite que se continúe la transacción y en caso de ausencia no se permite continuar o se bloquea el acceso a determinada información. Es a decisión del programador de la transacción en que momento se realiza el chequeo, a veces se verifica cuando uno ingresa un valor (por ejemplo la sociedad en la FB02) en donde se verifica el mismo objeto que antes F_BKPF_BUK, pero pidiendo la actividad 02 (modificar) y la sociedad para la cual va a realizarse la modificación (BUKRS).
NOTA 1: Tengamos que cuenta que los campos de un objeto de autorización siempre se verifican en conjunto, quiero decir que la actividad 02 (modificar) solo autoriza a la Sociedad que se encuentra dentro de la misma autorización. Podría ocurrir que dentro de un mismo rol tengamos permiso para modificar una Sociedad pero solo para Visualizar otra. Por eso es importante tener en cuenta que estas son verificadas “en bloque”
NOTA 2: También es importante destacar que es posible y hasta habitual que un usuario tenga más de un ROL asignado, en este caso se produce lo que se conoce como “suma de autorizaciones” y esto quiere decir que los valores solicitados de objetos de autorización pueden encontrarse en cualquiera de los roles que el usuario tiene asignado. Ejemplo: Si en el rol 1 el usuario tiene el acceso a la transacción FB02 (objeto S_TCODE), y en el objeto F_BKPF_BUK la actividad con valor 03 y la sociedad en 0001, pero el programa solicite 02 y 0001 el usuario no podría ingresar a la transacción. Ahora si agregamos un segundo rol al usuario sin ningún objeto S_TCODE pero con el objeto F_BKPF_BUK con valor de actividad 02 y sociedad 0001 el usuario ahora si va a poder tener acceso a ejecutar esta transacción (el primer rol le da el S_TCODE con FB02 y el segundo el F_BKPF_BUK con actividad 02)
Por último cabe destacar que la transacción FB02 necesita de otros objetos de autorización para ser ejecutada pero el nombrado aquí fue solo a modo de ejemplo. En un próximo post veremos un ejemplo completo.
