ambientedeseguridadenmdax12.docxapi.ning.com/.../ambientedeseguridadenmdax12.docx · web viewmodelo...

Modelo de seguridad de Microsoft Dynamics AX 2012 ERP

CAL’s de acceso

Todos los usuarios o clientes que acceden al MS Dynamics AX 2012 ERP, deberán contar con una licencia o CAL que les permita el acceso acierta funcionalidad del ERP. Las licencias de usuario pueden ser de cuatro tipos:

· Empresa: usuarios que necesitan acceder a la mayor parte o a toda la información en AX, ya que gestionan procesos a través de la organización

· Funcional: usuarios que requieren acceso a una cantidad considerable de información y que gestionan ciclos de negocio dentro de una división o unidad de negocio y no a través de varias unidades.

· Tareas: usuario que se conectará a AX para realizar una o varias tareas dentro de AX. · Autoservicio: aquellos usuario que accederán para gestionar sus propios datos

personales dentro del sistema.

Una de las claves de Microsoft Dynamics AX 2012 ERP es su focalización en las funciones de los usuarios y sus necesidades

El diseño basado en roles o funciones de la aplicación está soportado con un nuevo modelo de licencia que potencia que el cliente compre las licencias requeridas para cubrir las necesidades de sus usuarios.

Seguridad en MD AX 12 Página 1

Un rol de seguridad en el sistema MS Dynamics AX 2012 ERP (en adelante aparecerá como: MD AX 12) proporciona los derechos o deberes; privilegios y permisos de acceso a determinadas funciones que los usuarios necesitan realizar de acuerdo a su puesto de trabajo

A continuación, se muestra gráficamente como los Roles de Seguridad están implícitos dentro de algo llamado: Arquitectura de Seguridad del sistema AX

Autenticación de usuarios

Por defecto, solo los usuarios autentificados que tienen permisos de usuario del sistema en MD AX 2012 pueden establecer una conexión

Microsoft Dynamics AX 2012 utiliza la “”autentificación de Windows integrada”” pero si se configura MD AX 2012 para usar un proveedor de autentificación diferente, los usuarios serían autentificados mediante ese proveedor

NOTA: Autentificación de Windows integrada. Este término se utiliza para designar las conexiones autenticadas automáticamente entre Microsoft Internet Information Services (IIS), Internet Explorer y otras aplicaciones conectadas al Directorio Activo. Se trata igualmente de una forma segura de autenticación en la medida en que no se envían ni la contraseña ni el


nombre de usuario a través de la Red. En su lugar, el navegador tiene que demostrarle al servidor que conoce la clave por medio de un corto intercambio de datos, pero sin revelar nunca la clave, A diferencia de la autenticación básica o mediante resúmenes, no se le presenta al usuario una ventana para que introduzca su nombre y contraseña, sino que se utiliza la

Información de la sesión abierta por el ordenador del cliente, es decir, se utiliza el nombre de usuario, contraseña y dominio que se utilizó al entrar al ordenador desde el que se está navegando.

Después que el usuario se conecta a MD AX 2012, el acceso se determina mediante los deberes y privilegios que son asignados a los roles de seguridad al que el usuario pertenece

Detallando que son los ROLES DE SEGURIDAD

En la seguridad basada en roles o funciones, los permisos de acceso no se conceden a usuarios individuales sino a roles de seguridad y sustituyen a los grupos de usuarios utilizados en versiones anteriores de AX (por ej.: AX 2009)

Los usuarios son asignados a roles y por ese motivo, tendrán acceso a un grupo de privilegios que están asociados a cada rol

En Microsoft Dynamics AX, la seguridad basada en roles está alineada con la estructura de negocio. Los usuarios son asignados a roles de seguridad en función de sus responsabilidades en la organización y su participación en los procesos de negocio

El administrador concede accesos a las funciones o tareas que los usuarios realizan en un rol, no a elementos de programa que los usuarios deben usar

La autorización es el control de acceso a la aplicación de MD AX 12. Los permisos de seguridad definidos en los roles se usan para controlar el acceso a elementos individuales de la aplicación por ejemplo:

Menús, ejemplo de un Menú

Menú ítems


Acciones y botones de comando Informes o reportes, etc.

La autorización concede acceso a elementos de la aplicación. Por el contrario, la seguridad de datos deniega acceso a las tablas, campos y registros en la base de datos.

Modelo de seguridad


Este modelo de seguridad es jerárquico y cada elemento en la jerarquía representa un nivel diferente de detalle

Los Permisos representan accesos a objetos de seguridad individuales, por ejemplo, menú ítems y tablas

Los Privilegios están formados por permisos y dan accesos a tareas, como la cancelación de pagos y el procesamiento de depósitos de cobro

Las Funciones (Deberes) están compuestas de privilegios y representan partes de un proceso de negocio, como por ejemplo el mantenimiento de transacciones bancarias o bien a un catálogo maestro, ejemplo: Módulo Gestión de Información de Productos\Común\Productos salidos (este es el deber)

Tanto las funciones (deberes) como los privilegios se pueden asignar a los roles de seguridad para dar acceso a MD AX 12. Las funciones (deberes) son organizadas (os) en procesos de negocio o ciclos de negocio para ayudar al administrador a localizarlas para asignarlas a los roles, aquí es oportuno aclara lo siguiente: los ciclos de negocio por sí mismos no se pueden asignar a los roles.

Es decir, no encontramos en AX 12 algo que se llame, ciclo de negocio Ingresos o Egresos. Estos ciclos de negocio se componen de varios DEBERES que los conforman y que a su vez se encuentran en diferentes módulos, es decir, el ciclo Ingresos, se compone de los módulos, Comercial (retail); Ventas y Marketing; Cuentas por Cobrar; Gestión de efectivo y bancos (ciclo de punta a punta). Además, de que en este ciclo participan adyacentemente otros módulos que son necesarios, como por ejemplo: Gestión de Información de Productos; Gestión de Inventario y almacenes; Adquisición y abastecimiento; Contabilidad general, etc.

Dentro de un rol de seguridad, los administradores pueden aplicar políticas de seguridad de acceso a los datos a los que los usuarios tienen acceso, por ejemplo, un usuario en un rol puede tener acceso a información de solo una organización, y también puede especificar el nivel de acceso que los usuarios en un rol tienen en registros actuales, pasados o futuros, por ejemplo, los usuarios en un rol se pueden asignar a privilegios que les permita ver registros para todos los periodos, y que solamente puedan modificar los registros actuales.

Los roles de seguridad se pueden organizar dentro de una jerarquía permitiendo que los roles se puedan definir como combinaciones de otros roles.


En MD AX 2012, nos podemos encontrar con 78 roles de seguridad predefinidos, de los cuales 51 requieren la licencia de usuario (CAL) tipo Empresa, 21 al menos necesitan la licencia de usuario tipo Funcional y 6 precisan la licencia de usuario tipo Tarea. No hay ningún rol de seguridad predefinido que esté mapeado con la licencia de usuario tipo Autoservicio debido que esta licencia es para usuarios que solamente necesitan acceder al sistema para gestionar sus propios datos

Además hay cuatro roles ya definidos que conceden acceso a menú items que no necesitan ningún requerimiento de licencia ya que se han creado para ser asignados a usuarios externos: Cliente anónimo, Proveedor anónimo, Invitado y Candidato anónimo

Si los roles de seguridad entregados de forma predefinida con MD AX no cubren las necesidades de negocio, se pueden crear roles de seguridad personalizados modificando roles existentes o generándolos completamente nuevos.

En ese caso, es muy importante tener en cuenta que modificar roles puede afectar los requerimientos de licenciamiento y que esto lleve a que se necesite un tipo de licencia de usuario más alto (Enterprise). Es importante aclarar que, si un rol tiene un PERMISO y solo un permiso con nivel de licencia Enterprise, este rol consumirá una Licencia del tipo Enterprise (que es la licencia que te da acceso de Ver y Mantener) y cabe añadir que también es la que más cuesta. Así que considérenlo cuando personalicen un ROL nuevo o modifiquen uno que existe.


En esta imagen se muestra un Menú Item con Permiso de nivel de licencia Enterprise que da acceso a que un ROL de seguridad pueda crear Plantillas de Artículos, se ve claramente como fue mencionado que el nivel de licenciamiento requerido, es ENTERPRISE

Imagen del Catálogo de Gestión de información de artículos en donde se muestra la función de Aplicar Plantillas que a nivel de Licenciamiento requiere una licencia Enterprise. Observen un detalle en esta imagen, la etiqueta que aparece debajo de a Aplicar Plantilla (Aplicar una plantilla con valores de producto predefinidos) se corresponde con el campo Help text dentro de la propiedades del Menú Item dentro del AOT (ver imagen del AOT más abajo)

Imagen en el AOT (Application Object Three (Árbol de objetos de aplicación) en dónde se hace la búsqueda del Permiso que concede acceder a esta función de aplicar plantillas y se muestra el nivel de licenciamiento

Campo Help text dentro de la propiedades del Menú Item dentro del AOT


Pantalla del Módulo de Administración del sistema donde se encuentra el apartado de SEGURIDAD para configurar los Roles de seguridad para acceder al sistema

Dentro de este módulo las secciones que vamos a utilizar para configurar los Roles de Seguridad son:

CHB/Administración del sistema/Página de área/Común/Usuarios/Usuarios


CHB/Administración del sistema/Página de área/Configurar/Seguridad/Roles de seguridad

Dentro de CHB/Administración del sistema/Página de área/Común/Usuarios/usuarios se encuentran todos los usuarios que fueron importados desde el Directorio Activo de Windows 2008. Cada unos de estos usuarios se han importado porque van a estar asignados a un rol o roles de seguridad para realizar su trabajo de acuerdo a sus funciones

Dentro de CHB/Administración del sistema/Página de área/Configurar/Seguridad/Roles de seguridad, se encuentran todos los 78 roles pre-definidos que contiene el MD AX 12 y los nuevos roles que se crearan por necesidad de configuraciones específicas


Importando usuarios del Active Directory o Directorio Activo (AD o DA) a MD AX 12

Como se menciono anteriormente, en la seguridad basada en roles o funciones, los permisos de acceso no se conceden a usuarios individuales sino a roles de seguridad, los usuarios son asignados a roles y por ese motivo, tendrán acceso a un grupo de privilegios que están asociados a cada rol

Para importar un usuario desde el AD o DA tenemos que entrar al formulario de usuarios que se encuentra en la siguiente ruta:

CHB/Administración del sistema/Común/Usuarios/Usuarios

En este formulario se encuentran todos los usuarios que fueron importados desde el Directorio Activo de Windows 2008. Cada unos de estos usuarios se han importado porque van a estar asignados a un rol o roles de seguridad para realizar su trabajo de acuerdo a sus funciones

Para importar un usuario nuevo, vamos a dar clic en el ícono Importar que esta en el panel principal de tareas de ese formulario

Esta acción, desplegará el asistente de importación de Active Directory para importar usuarios a MD AX 12

A través de una serie de ventanas nos llevará de la mano para importar uno o varios usuarios al mismo tiempo


Al dar clic en el botón aparece la ventana donde tenemos que seleccionar los parámetros que se muestran en ella

Al dar clic en el botón aparece el siguiente mensaje


Dar clic en el botón con la etiquete Yes para continuar y aparece la siguiente ventana

Donde se seleccionara el usuario o usuarios (si es el caso) que se importarán desde el Directorio Activo, para fines de este ejemplo, solo importaremos el usuario Aux.ch como lo muestra la imagen

Al dar clic en el botón aparece la siguiente ventana, donde de alguna manera todavía podemos hacer una confirmación del usuario que vamos a importar, si fuera más de un usuario, podemos hacer una selección de los que queremos importar, descartando los que no se importaran


Al dar clic en el botón aparece la siguiente ventana, en donde el asistente nos solicita (si así lo decidiéramos) asignar al usuario a un rol o roles de los que están disponibles en MD AX 12, como se muestra en la siguiente imagen

Al dar clic en el botón aparece la siguiente ventana en donde se seleccionará la

opción


Al dar clic en el botón aparece la ventana que finaliza el asistente de importación de usuarios, como lo muestra la siguiente imagen

Al finalizar el asistente buscaremos el usuario Aux.ch dentro del formulario de Usuarios como lo muestra la siguiente imagen.

Estando en este formulario nos vamos a cerciorar de que el usuario Aux.ch fue asignado al rol GTEP1 que fue el rol que se selecciono durante el asistente de importación de usuarios, esto lo

haremos dando clic en el botón con la etiqueta

Al dar clic en el botón aparece la siguiente ventana, en donde vemos que efectivamente el usuario fue asignado al rol llamado GTE1P como lo muestra la siguiente imagen


En Microsoft Dynamics AX, la seguridad basada en roles, está alineada con la estructura de negocio, por lo tanto es importante entender como se conforma un Rol de seguridad en el sistema

Entendiendo que son Deberes, privilegios y permisos

Deber o funciones. Un Deber es un agrupador de privilegios y representan parte de un proceso de negocio como por ejemplo:

Privilegios. Los privilegios representan tareas que están contenidas dentro de un Deber y representan lo que el nombre del Deber da a entender que hacen, aunque algunas veces no es tan claro. Ejemplo, los privilegios que contiene el Deber, Mantener el registro de inventarios

Este Deber contiene 3 privilegios y una pequeña descripción de lo que se puede hacer con estos al asignárselos a un Rol

A su vez, cada privilegio contiene un número determinado de Permisos, estos permisos, son el nivel más alto dentro de la seguridad de MD AX 12 y otorgan al rol, el nivel de acceso que tiene para ejecutar dicho Permiso. En este ejemplo, el permiso tiene el nombre AOT,


PdsVendBatchEditLines(Detalles del lote del Proveedor) con un nivel de acceso de, Control Total

Los niveles de acceso del Permiso, son los siguientes:

SEGURIDAD DE NIVEL DE REGISTRO

Cuando se requiere configurar la seguridad de nivel de registro se debe conocer la tabla o tablas especificas que se van a utilizar en dicha configuración, dentro de las cuales, se encuentra el campo o campos que llevaran un valor para limitar el acceso a los usuarios que se asignaron aun rol de seguridad dentro del sistema MS Dynamics AX 2012. Dicho rol, le permite al usuario acceder a los formularios de los módulos que necesita manipular en el sistema

Entendiendo como se llega a la seguridad de nivel de registro

Conociendo la tabla o tablas para configurar la seguridad de nivel de registro


Asignar Tablas para la seguridad a nivel de registro

Como se menciono unos párrafos arriba, la seguridad de nivel de registro utiliza las tablas del sistema MD AX 12 para limitar el acceso a nivel de campo de esas tablas, configurando a ese campo con un parámetro que le otorga un valor que limita al rol a ver cierta información. A continuación se verá como se configura este nivel de seguridad, tomando como ejemplo un Rol de Gerente de Tiendas y específicamente con el Rol GteLeon

Configurando la seguridad a nivel de registro para el ROL GteLeon

Se deben realizar ciertos pasos previos para conocer el nombre de la tabla o tablas involucradas en la seguridad de nivel de registro, por ejemplo:

Conocer el módulo (ejemplo: Ventas y Marketing o Adquisición y Abastecimiento) Conocer el formulario al que se accede y que contiene el campo o campos que se

quieren limitar

Conocer o saber cual es la tabla Principal o padre que contiene los campos de las demás tablas que están involucradas dentro del formulario (Conformada por Vistas)

Y, Conocer el nombre de la tabla física que contiene ese campo

Pantallas que ilustrarán un Ejemplo:

Ir a la siguiente Ruta: CHB/Adquisición y abastecimiento (Módulo)/Común/Órdenes de compra (Deber)/Todas las órdenes de compra (Formulario)


Objetivo. Se debe conocer el nombre de la tabla Principal o padre que contiene las líneas de la Orden de Compra (OC). Para ello, dentro del formulario de las Órdenes de Compra (OC) se editan las Líneas de dicha Orden y se da clic con el botón derecho del mouse sobre la sección Líneas de la orden de compra para desplegar un Menú que muestra dos opciones: Personalizar y Ver registro, para nuestro caso, utilizaremos la opción Personalizar para conocer el nombre de la Tabla Principal que contiene el campo Almacén y que servirá para limitar el acceso del Rol a ver solo las transacciones de su almacén a nivel de las líneas de la O de C

Se despliega la siguiente ventana o formulario


Dentro del Panel de Diseño, hay dos bloques, ActionPaneHeader (Encabezado que contiene las funciones de cada pestaña) como se muestra en la siguiente pantalla

Y que se corresponden con las pestañas en el formulario de Órdenes de Compra (OC), como lo muestra la siguiente imagen


En letras Negritas esta el nombre del otro bloque llamado MainTab, que nos indica que ese es el bloque a Editar para nuestro caso. Aquí, buscaremos el campo Almacén dentro del árbol de opciones, NOTA: la búsqueda es muy sencilla ya que los nombres en el árbol se corresponden con los nombres en el formulario, como se muestra en la siguiente pantalla

Desplegando el asistente para configurar la seguridad de nivel de registro

Ir a la siguiente ruta: CHB/Administración del sistema/Página de área/Configurar/Roles de Seguridad

Nos posicionamos en el nombre del rol (GteLeon) al que se le configurará la seguridad de nivel de registro y damos clic con el botón izquierdo del mouse en la función, Seguridad de Nivel de registro para que se despliegue la ventana que contiene el asistente, como se muestra en la siguiente pantalla


Una vez ahí, damos clic en la opción Nuevo para desplegar el asistente


Iremos dando clic en el botón de siguiente para ir paso a paso en la configuración de la seguridad

Seleccionamos el rol del gerente de la sucursal de León

Dar clic en el botón siguiente, al tratar de continuar al siguiente paso, el sistema se tomará unos cuantos minutos porque hace una búsqueda de las tablas del sistema, terminada la búsqueda, debemos de seleccionar la opción: Mostrar todas las tablas como se muestra la siguiente imagen. Por default el asistente solo muestra las tablas principales por lo que al dar clic en el botón de radio y seleccionar Mostrar todas las tablas, el asistente desplegara todas y podremos hacer una búsqueda con la certeza de que encontraremos la tabla o tablas que requerimos o que se requieren


Tendremos que realizar una búsqueda por ciclo de proceso para encontrar la tabla principal que contiene el campo Almacén que está dentro del formulario Órdenes de Compra (OC) a nivel de las Líneas de la orden

Aquí, es necesario aclarar, que el asistente no nos ayuda mucho para poder encontrar la Tabla o Tablas que necesitamos agregar para configurar la seguridad a nivel de registro, Por ejemplo, si queremos buscar la tabla principal dentro de los ciclos de proceso de Adquisición I y Adquisición II porque nos suena lógico y relacionamos su nombre porque se corresponde con el Módulo de Adquisición y Abastecimiento, nos vamos a encontrar con que esa tabla no se encuentra ahí


¿Entonces cómo poder encontrar ayuda para localizarla?

Regresemos a la ventana donde se mostró que al seleccionar la opción Personalizar encontramos la información dentro de un árbol con estructura de directorios parecida a la del explorador de directorios de Windows

Dentro de los paneles de la derecha, existe otro Panel llamado Configuration Keys el cual nos puede dar una idea del ciclo de proceso donde se encuentra la Tabla InventDim, como muestra la pantalla o imagen siguiente


Nos da una referencia de que esa tabla se encuentra en el ciclo de proceso Comercio y Contabilidad general, para nuestro caso requerimos buscar esa tabla dentro del proceso Comercio, ya que requerimos las dimensiones de almacenamiento y NO requerimos información de tablas contables; vayamos pues al asistente y busquemos dentro de dicho ciclo la tabla Principal (hasta el momento, no se sabe cual es)

Expandimos dicho ciclo Comercio como se muestra en la imagen siguiente


Ahora busquemos la tabla principal ¿cómo?

Aquí también nos encontraremos con que no es muy sencillo realizar la búsqueda, pero intentemos de nuevo encontrar ayuda, vayamos una vez más al formulario Personalizar y tratemos de ver si nos ofrece la ayuda necesaria

Si nos damos cuenta, el campo Almacén se encuentra en la rama llamada, Líneas de la orden de compra dentro del árbol, aquí, es necesario explicar antes que a nivel de tabla, hay que conocer dentro de cual tabla “Principal” se encuentra el campo almacén, ya que, dentro de los formularios de MD AX 12 suelen encontrarse “Vistas”, que, no son otra cosa que objetos del


AOT y de la Base de Datos MS SQL Server que se conforman de varias tablas anidadas o unidas por Uniones o Joins que permiten que varios campos de varias tablas se puedan conjuntar dentro de un solo Formulario, como se tratara de explicar con las siguiente imágenes

Vayamos nuevamente dentro del formulario Personalizar, ahí se encuentra una rama del árbol que se llama Líneas de la orden de compra que se corresponde perfectamente con la parte llamada líneas de la Orden de compra que se encuentran en el formulario de las Órdenes de compra (OC), como se puede ver en las siguientes imágenes

Opción Personalizar del formulario Órdenes de compra (OC), que contiene el nombre Líneas de la Orden de Compra


Que se corresponde con el nombre Líneas de la orden de compra del Formulario de las Órdenes de compra (OC)

Sabiendo que, como ya se había mencionado en párrafos anteriores, los nombres de los formularios se corresponden con los nombres dentro de la opción de Personalizar de cada uno de ellos, se mostrara a continuación el nombre de la tabla Principal o Padre que contiene a las demás tablas utilizadas en el formulario Órdenes de Compra (OC)

Dentro de la opción Personalizar y posicionándose en la etiqueta Líneas de la orden de compra se encuentra otra etiqueta con el nombre LineSpec, la cual contiene los campos que conforman a la rama Líneas de la orden de compra dentro del formulario de las Órdenes de compra (OC), las etiquetas de los campos de la tabla que están a nivel de la raíz LineSpec y que no tienen un signo de +, son campos de la tabla Principal o Padre y los que tiene un signo de +, son campos que forman parte de otra tabla o tablas, por lo tanto, nosotros debemos saber el nombre de la tabla principal para poder buscarla dentro del asistente de configuración de la Seguridad a nivel de registro, como se muestra en la siguiente pantalla dentro del panel derecho llamado Nombre del sistema


Para nuestro caso, la tabla principal se llama: PurchLine, con este dato vayamos al asistente y busquemos dentro del ciclo Comercio la tabla PurchLine

Búsqueda de la tabla


Seleccionamos la tabla colocando una palomita en la casilla que está del lado izquierdo del nombre de la tabla para poder agregarla y configurarla, finalmente dar clic en el botón con la etiqueta Siguiente; aparece la siguiente ventana que finaliza el asistente al darle clic en el botón con la etiqueta Finalizar


Con esto, ahora podemos proceder a configurar la consulta que nos permitirá filtrar por el campo No de Dimensión y con esto restringir al Rol del Gerente de la sucursal de León a que vea solo las líneas de la Orden de compra de su Almacén

En la ventana principal de la seguridad de nivel de registro, podemos ver que se agrega la tabla PurchLine cuyo nombre dentro del formulario de Órdenes de Compra (OC) se llama, Líneas de la orden de compra. Para configurar la consulta se da clic en el botón con la etiqueta Consulta

Esta acción nos lleva a la siguiente ventana


Aquí, configuraremos el campo llamado No de Dimensión, que es un arreglo que hace MD AX 12 para conformar en una sola Dimensión o arreglo, tanto al Almacén como al Sitio que se utilizan al crear una Orden de compra y que al efectuar alguna transacción este arreglo crea un numero de referencia en la tabla física, lo que permite tener más coherencia en el manejo de la información en la Base de datos.

Para configurar el No de dimensión se pueden editar cualquiera de las dos líneas que se encuentran en esta ventana, para este ejemplo será la primera línea, después, se edita el campo Criterios y se hace la búsqueda por el campo Almacén oprimiendo a la misma vez la combinación de teclas Ctrl + K, la búsqueda se hace entre asteriscos *T044* y nos arroja que el No de Dimensión para el Almacén/Sitio de la sucursal de León, que es, CHB-000261


Se da clic en el botón de Aceptar y finaliza la creación de esa consulta.

NOTA. Cada una de las configuraciones de Seguridad de nivel de registro y sus consultas requeridas para los roles de Gerente de tienda, hará necesario llevar a cabo el mismo procedimiento

Ejemplo 2.

Tabla: Almacén. Nombre dentro del AOT, InventLocation

Funcionalidad. Configurar para cada sucursal o tienda los almacenes a los que tendrá acceso para transaccionar Órdenes de Compra. Para este caso, los almacenes serán, C241-CED que se corresponde con el almacén del CEDIS y el propio almacén de su tienda


ambientedeseguridadenmdax12.docxapi.ning.com/.../ambientedeseguridadenmdax12.docx · web viewmodelo...

Documents