Modelo de Autorización
El Modelo de Autorización expone un punto de entrada para verificar los privilegios de acceso de un usuario mediante la consulta de un modelo de autorización configurable, granular y basado en grupos. El modelo se utiliza para definir un protocolo de autorización detallado para varios componentes de IPF a través del IPF. Operational Dashboard. El modelo de autorización mencionado anteriormente cubre actualmente el HTM Puntos finales de servicio en el Panel de IPF. Se tiene la intención de implementarlo en otros componentes de IPF en un futuro cercano.
Protocolo de Autorización Granular Basado en Grupos
El modelo de autorización granular basado en grupos proporciona la capacidad de definir un acceso detallado a HTM tareas, ya que los permisos se calculan teniendo en cuenta no solo los roles, sino también los contextos específicos del sistema. Esto permite a los clientes configurar este tipo de modelo de autorización, que otorga acceso limitado a tareas filtradas por propiedades específicas a diferentes equipos en la empresa.
Ejemplo de Configuración
A continuación, puede ver un ejemplo de un modelo de autorización finamente ajustado para el acceso a HTM puntos finales.
ipf.authorisation {
processing-entities = [
{
name: "BANK_ENTITY_1",
code: "BE1"
},
{
name: "BANK_ENTITY_2",
code: "BE2"
},
]
groups = [
{
name: "ADMIN_GROUP",
bankEntities: {
"BANK_ENTITY_1": ["ROLE_1", "ROLE_2", "ROLE_3", "ROLE_4"],
"BANK_ENTITY_2": ["ROLE_1", "ROLE_2", "ROLE_3", "ROLE_4"],
}
},
{
name: "GROUP_1",
bankEntities: {
"BANK_ENTITY_1": ["ROLE_1", "ROLE_3"]
},
},
{
name: "GROUP_2",
bankEntities: {
"BANK_ENTITY_2": ["ROLE_2", "ROLE_4"]
}
}
],
roles = [
{
role: "ROLE_1",
permissions: [
{
system: "System1",
actions: ["VIEW"]
context: {
"taskType": ["REPAIR"],
"metaData": ["CURRENCY:USD"]
}
}
]
},
{
role: "ROLE_2",
permissions: [
{
system: "System2",
actions: ["VIEW"]
context: {
"taskType": "REPAIR"
}
}
]
},
{
role: "ROLE_3",
permissions: [
{
system: "System1",
actions: ["CREATE"]
}
]
}
{
role: "ROLE_4",
permissions: [
{
system: "System1",
actions: ["CREATE", "UPDATE", "CANCEL", "VIEW"]
context: {
"taskType": "REPAIR",
"metaData": ["CURRENCY:GBP"]
}
}
]
}
]
}Conceptos Clave en el Modelo de Autorización Granular
processing-entities: Esta entrada contiene una lista de objetos ProcessingEntity. ProcessingEntity (no debe confundirse con el objeto ProcessingEntity más utilizado en IPF) tiene dos propiedades: name y code.
grupos: Una lista de objetos Grupo. Contiene un Mapa de entidades de procesamiento con roles agrupados.
roles: Una lista de roles definidos con los permisos aplicables respectivos.
permisos: Una lista de permisos por sistema asociados con un rol.
Analicemos las partes principales de un permiso para entender cómo podemos aprovecharlo para lograr una autorización granular.
system: Atributo obligatorio. Define a qué sistema pertenecen los permisos. Actualmente, solo HTM los endpoints están integrados con el nuevo enfoque de autorización. Así que, el sistema está configurado en " HTM.
acciones: Atributo obligatorio. Una lista de valores String que están en línea con los valores del enum definidos programáticamente HTMAction.
context: Atributo opcional. Es un Mapa de pares <String, Object> que hace que permissions sea granular en función de las propiedades de la tarea. HTM los endpoints en el servicio de panel de control transmiten automáticamente 2 filtros diferentes, si se proporcionan, para ser enviados a la HTM Llamadas de servicio. Estos son task Type y meta Data.
Revisemos cómo la inclusión de estos atributos en un contexto afecta a qué tipo de tareas se pueden aplicar los permisos configurados. Las opciones a continuación se describen desde la menos restrictive a lo más restrictive privilegio de acceso.
- Tipo de contexto 1
-
El contexto se omite dentro de la definición del rol. Esto garantiza privilegios de administrador al usuario para ejecutar cualquiera de las acciones especificadas dentro de permisos en todas las tareas.
-
E.j.: ROLE_3 en [Example Configuration] tiene un privilegio de administrador, ya que el contexto específico del sistema no está definido para este rol.
-
- Tipo de contexto 2
-
Solo taskType está configurado en el contexto. El tipo de tarea debe configurarse como una <String, String> clave.- par de valores. En consecuencia, está prohibido especificar múltiples valores para un taskType.
-
E.j.: rol ROLE_2 en [Example Configuration]. Este rol especifica "taskType": "REPAIR". Un usuario que pueda ocupar este rol (dentro del grupo asociado) solo puede ver y actualizar aquellas tareas que tengan la propiedad taskType de REPAIR.
-
- Tipo de contexto 3
-
Tanto taskType como metaData están definidos en el contexto. Esto indica el más restricted acceso a tareas como resultado de los filtros aplicados.
-
E.j.: ROLE_1 rol en [Example Configuration]. Un usuario que podría ocupar este rol (dentro del grupo asociado), solo puede ver en la pantalla aquellas tareas que tienen un tipo de tarea de REPAIR y etiquetas de metadatos adjuntas de "CURRENCY:USD".
-
Registro de un Sistema con el Modelo de Permisos
Se requiere registrar una SystemDefinition para el sistema dado que implementa un modelo de autorización granular, el cual define, en consecuencia, las Actions de soporte y un Context Adapter opcional.
Reglas a seguir para anular correctamente la configuración:
La implementación del cliente debe anular ipf.authorisation.conf si desea aprovechar la autorización granular.
-
Asegúrese de que la lista de permisos esté correctamente definida. En primer lugar, todos los valores deben ser las representaciones en cadena de los enumerados HTMAction. En segundo lugar, view es el privilegio mínimo que un rol debe tener para acceder a acciones adicionales. Si a un rol se le permite realizar acciones adicionales que modifiquen la tarea de alguna manera, se debe asegurar que el permiso de VISUALIZACIÓN siga incluido en la lista. Esto es para asegurar que la tarea dada se devuelva al usuario en la consulta de búsqueda inicial al iniciar sesión.
-
Para reiterar, un taskType en un contexto debe contener únicamente un único valor de String.
-
Un Grupo puede tener diferentes Roles con contextos muy distintos. Permisos así como contextos son aditivos. En el escenario de determinar el alcance autorizado de un usuario para ver tareas, se utilizan todos los tipos de tareas, así como las etiquetas de metadatos definidas en los roles respectivos, como filtros en la consulta. Tenga en cuenta que, en el caso de roles con privilegios de administrador, se anulan los contextos adjuntos a otros roles.
-
Para demostrar la naturaleza aditiva de los permisos, examinemos [Configuration Layout of a highly granular Authorisation Model] en el Apéndice. Supongamos que hay un usuario que pertenece al grupo SANCTIONS. Este grupo abarca los roles SANCTIONS_EXECUTE y SANCTIONS_APPROVE (consulte los roles en la configuración de ejemplo anterior). En consecuencia, el usuario puede ver, asignar, ejecutar, aprobar y rechazar cualquier tarea que tenga el tipo COMPLIANCE y los metaDataTags COMPLIANCETYPE:SANCTIONS.
-
Servicio de Autorización
Expone el método sobrecargado de la función isPermitted:
public <X extends Action, T extends AggregatedPermissionContext> PermittedResult<T> isPermitted(String processingEntityName, List<String> groupNames, SystemDefinition<?, X> system, X action
Los controladores en el servicio de panel interactúan con esta única función para determinar si un usuario dado puede acceder al recurso solicitado, identificado por el sistema y una acción.
1. Sección
1.1. Protocolo de Autorización Actual Utilizado Para Acceder API Puntos finales en el Panel de control
A tener en cuenta, actualmente todos los puntos finales en el servicio, sean que ODS, o CSM Reachability, utilice un modelo de autorización basado en roles. A partir de este momento, procedemos a utilizar HTM APIs para ilustrar el uso del modelo de autorización actual. Se asigna a un usuario uno o más de los siguientes roles para obtener acceso a HTM Tareas en el panel de control:
-
ROL_HTM_VISOR
-
ROL_HTM_EJECUTAR
-
ROL_APROBADOR_HTM
Dependiendo de cuál o cuáles de los roles se le asignen al usuario, este está autorizado para ver y posiblemente ejecutar diversas acciones adicionales en las tareas. Este enfoque proporciona acceso ilimitado al usuario para acceder a todas las tareas, siempre que esté autorizado para hacerlo.
2. Sección
2.1. Configuración predeterminada compatible hacia atrás
ipf.authorisation {
processing-entities = [
{
name: "BANK_ENTITY_1",
code: "BE1"
},
{
name: "BANK_ENTITY_2",
code: "BE2"
},
{
name: "BANK_ENTITY_3",
code: "BE3"
},
]
groups = [
// Groups to ensure backward compatibility using current role definitions
{
name: "ROLE_HTM_VIEWER",
bankEntities: {
"BANK_ENTITY_1": ["ROLE_HTM_VIEW"],
"BANK_ENTITY_2": ["ROLE_HTM_VIEW"],
"BANK_ENTITY_3": ["ROLE_HTM_VIEW"],
}
},
{
name: "ROLE_HTM_EXECUTE",
bankEntities: {
"BANK_ENTITY_1": ["ROLE_HTM_EXECUTE_AND_ASSIGN"],
"BANK_ENTITY_2": ["ROLE_HTM_EXECUTE_AND_ASSIGN"],
"BANK_ENTITY_3": ["ROLE_HTM_EXECUTE_AND_ASSIGN"],
}
},
{
name: "ROLE_HTM_APPROVER",
bankEntities: {
"BANK_ENTITY_1": ["ROLE_HTM_APPROVE_AND_REJECT"],
"BANK_ENTITY_2": ["ROLE_HTM_APPROVE_AND_REJECT"],
"BANK_ENTITY_3": ["ROLE_HTM_APPROVE_AND_REJECT"],
}
},
],
roles = [
{
role: "ROLE_HTM_VIEW",
permissions: [
{
system: "HTM",
actions: ["VIEW"]
}
]
},
{
role: "ROLE_HTM_EXECUTE_AND_ASSIGN",
permissions: [
{
system: "HTM",
actions: ["VIEW", "ASSIGN", "EXECUTE"]
}
]
},
{
role: "ROLE_HTM_APPROVE_AND_REJECT",
permissions: [
{
system: "HTM",
actions: ["VIEW", "APPROVE", "REJECT"]
}
]
},
]
}La configuración predeterminada asegura que los usuarios actuales mantengan los mismos privilegios de acceso que tenían con el enfoque anterior.
2.2. Diseño de Configuración de un Modelo de Autorización altamente granular
A continuación, puede ver un ejemplo de un modelo de autorización ajustado para el acceso a HTM puntos finales.
ipf.authorisation {
processing-entities = [
{
name: "BANK_ENTITY_1",
code: "BE1"
},
{
name: "BANK_ENTITY_2",
code: "BE2"
},
{
name: "BANK_ENTITY_3",
code: "BE3"
},
]
groups = [
{
name: "HTM_ADMIN_GROUP",
bankEntities: {
"BANK_ENTITY_1": ["ADMIN_TEAM", "SANCTIONS_EXECUTE"],
"BANK_ENTITY_2": ["ADMIN_TEAM"],
}
},
{
name: "HTM_OPERATOR_GROUP_1",
bankEntities: {
"BANK_ENTITY_1": ["GB_ACCOUNTS_TEAM", "ACCOUNTS_SYSTEM_A_APPROVE"],
"BANK_ENTITY_2": ["GB_ACCOUNTS_TEAM", "ACCOUNTS_ADMIN_TEAM"]
},
},
{
name: "HTM_OPERATOR_GROUP_2",
bankEntities: {
"BANK_ENTITY_1": ["US_ACCOUNTS_TEAM", "ACCOUNTS_SYSTEM_A_EXECUTE"]
"BANK_ENTITY_2": ["US_ACCOUNTS_TEAM", "FRAUD_APPROVE"]
}
},
],
roles = [
{
role: "US_ACCOUNTS_TEAM",
permissions: [
{
system: "HTM",
actions: ["VIEW"]
context: {
"taskType": "REPAIR",
"metaData": ["CURRENCY:USD"]
}
}
]
},
{
role: "GB_ACCOUNTS_TEAM",
permissions: [
{
system: "HTM",
actions: ["VIEW"]
context: {
"taskType": "REPAIR"
"metaData": ["CURRENCY:GBP"]
}
}
]
},
{
role: "ACCOUNTS_SYSTEM_A_EXECUTE",
permissions: [
{
system: "HTM",
actions: ["VIEW", "ASSIGN", "EXECUTE"]
context: {
"taskType": "REPAIR"
"metaData": ["ACCOUNTSYSTEM:A"]
}
}
]
},
{
role: "ACCOUNTS_SYSTEM_A_APPROVE",
permissions: [
{
system: "HTM",
actions: ["VIEW","APPROVE", "REJECT"]
context: {
"taskType": "REPAIR"
"metaData": ["ACCOUNTSYSTEM:A"]
}
}
]
},
{
role: "ACCOUNTS_SYSTEM_B_APPROVE",
permissions: [
{
system: "HTM",
actions: ["VIEW", "ASSIGN", "EXECUTE", "APPROVE", "REJECT"]
context: {
"taskType": "REPAIR"
"metaData": ["ACCOUNTSYSTEM:B"]
}
}
]
},
{
role: "SANCTIONS_EXECUTE",
permissions: [
{
system: "HTM",
actions: ["VIEW", "ASSIGN", "EXECUTE"]
context: {
"taskType": "COMPLIANCE"
"metaData": ["COMPLIANCETYPE:SANCTIONS"]
}
}
]
},
{
role: "SANCTIONS_APPROVE",
permissions: [
{
system: "HTM",
actions: ["VIEW", "APPROVE", "REJECT"]
context: {
"taskType": "COMPLIANCE"
"metaData": ["COMPLIANCETYPE:SANCTIONS"]
}
}
]
},
{
role: "FRAUD_EXECUTE",
permissions: [
{
system: "HTM",
actions: ["VIEW", "ASSIGN", "EXECUTE"]
context: {
"taskType": "COMPLIANCE"
"metaData": ["COMPLIANCETYPE:FRAUD"]
}
}
]
},
{
role: "FRAUD_APPROVE",
permissions: [
{
system: "HTM",
actions: ["VIEW", "APPROVE", "REJECT"]
context: {
"taskType": "COMPLIANCE"
"metaData": ["COMPLIANCETYPE:FRAUD"]
}
}
]
},
{
role: "ACCOUNTS_ADMIN_TEAM",
permissions: [
{
system: "HTM",
actions: ["VIEW", "APPROVE", "REJECT"]
context: {
"taskType": "REPAIR"
}
}
]
},
{
role: "ADMIN_TEAM",
permissions: [
{
system: "HTM",
actions: ["VIEW", "ASSIGN", "EXECUTE", "APPROVE", "REJECT"]
}
]
},
]
}