¿Cómo manejar las reclamaciones dependientes de los datos?

Question

¿Cómo manejar las reclamaciones dependientes de los datos?

#1 de Steve (2 votos)
#2 de David Brossard (0 votos)

0

Esta pregunta es sobre la autorización basada en reclamaciones y Windows Identity Foundation (desafortunadamente, no tengo el privilegio de crear una etiqueta para esto).

Considere el siguiente caso de uso simple:

Tengo un usuario de clase y un proyecto de clase,
(por simplicidad) cada proyecto tiene exactamente un usuario asignado,
La política de control de acceso es que

Un usuario solo puede leer datos de proyectos a los que está asignado.

Estoy intentando modelar esto utilizando WIF y Autorización basada en reclamaciones.

Por lo tanto, tengo el siguiente método para el cual quiero verificar el acceso:

public Project ReadProject(int id)

Para hacer esto, tendría que hacer una llamada a la ClaimsAuthorizationManager con un AuthorizationContext que contiene el principal (= el usuario) y las Reclamaciones de los recursos a los que desea acceder y las acciones que desea realizar en estos recursos.

Lo que no tengo claro: En el caso de uso anterior, el permiso se basa en el hecho project.AssignedUserID == user.ID . ¿Cómo serían las reclamaciones?

¿Este requisito es un reclamo para el usuario / director, como "El usuario tiene acceso a la ID del proyecto X", que debo configurar antes de llamar al Administrador de autorizaciones de reclamaciones? En caso afirmativo, ¿en qué momento asignaría esa reclamación al usuario? ¿Y eso no arruinaría todo el punto de tener un lugar centralizado para declarar y verificar políticas?
¿Es más bien algo que el Administrador de Autorizaciones de Reclamaciones verificará al buscar la base de datos? Si es así, ¿cómo traduciría el hecho a qué proyecto quiere acceder en un Reclamo?

La mayoría de los ejemplos que encuentro para CBA se basan en los atributos del usuario (por ejemplo, de qué país es), por lo que no tengo idea de cómo realizar verificaciones en la relación de datos de usuario.

authorization access-control permissions .net

pregunta magnattic 08.05.2014 - 16:49

fuente

2 respuestas

Lea otras preguntas en las etiquetas authorization access-control permissions .net

Cifrado y descifrado sin estado A cambio de libc, ¿cómo sabe la dirección del sistema () en una máquina remota?

score 2 · Answer 1

Bueno, hay un par de opciones aquí. Lo primero es revertirlo de modo que su usuario tenga una colección de reclamos que definan a qué proyectos tienen acceso:

Reclamaciones:

Proyecto: 123
Proyecto: 124
Proyecto: 125
Proyecto: 129

Esto podría ser inmanejable dependiendo de la frecuencia con la que se crean los proyectos y la cantidad de proyectos por usuario, ya que tendrá que actualizar las reclamaciones cada vez que algo cambie.

Puede realizar una comprobación de la base de datos en CAM, pero se hace ruidos rápidamente y potencialmente puede ralentizar el sistema considerablemente, ya que el CAM está diseñado para ser llamado con frecuencia. Si es posible, solo debe tomar sus decisiones en base a las reclamaciones presentes en el director.

Alternativamente, puede pasar un recurso compuesto como "proyecto: {id}: {assignUserId}" y su CAM podría analizarlo así que si el recurso comienza con "proyecto" puede analizar el ID del proyecto y el ID de usuario asignado. y haga una verificación para ver si los reclamos principales contienen algo como 'UserId: 123'. El Id. Del proyecto no sería necesariamente necesario en este caso, pero si está ingresando al CAM, podría ser útil incluir el Id. Del proyecto también.

score 0 · Answer 2

Necesita control de acceso basado en atributos. El control de acceso basado en reclamos es poderoso pero no lo suficientemente flexible aquí en particular porque tiene que pensar en todos los reclamos posibles por adelantado.

El control de acceso basado en atributos (como se define aquí por NIST ) asume la premisa de que todo se puede describir en términos de atributos: usuarios, recursos, contexto y acción.

Con eso en mente, tome su requisito de autorización original

Un usuario solo puede leer datos de proyectos a los que está asignado.

El siguiente paso es identificar los atributos:

action == read
resourceType == datos
dataProject
userAssignedProject

Luego, puede volver a escribir su requisito de autorización en términos de estos atributos.

Un usuario puede hacer la acción == leer en el recurso de resourceType == datos si y solo si dataProject está en la lista de userAssignedProject.

La siguiente pregunta es: ¿cómo implementas esto? Use XACML, el eXtensible Access Control Markup Language , el estándar de facto para la autorización que se ha desarrollado durante los últimos 12 años en OASIS .

XACML te da:

una arquitectura
un lenguaje de política
un esquema de solicitud / respuesta.

ConXACMLpuedeexternalizarcompletamentesuautorización,demodoquesucódigosecentraexclusivamenteenlalógicadenegociosyluegollamaalacapadeautorización.

Unodelosbeneficiosclaveesquesicambiasurequisitodeautorizaciónoriginal,puedeactualizarfácilmentesupolíticadeautorizaciónynotocarelcódigoenabsoluto.

EsteeselaspectoquetendríasupolíticaenelpseudocódigodeALFA:

/***Controlaccesstodatainprojects*/policyaccessData{targetclauseactionId=="read" and resourceType=="data" 
    apply firstApplicable
    /**
     * Allow if same project
     */
    rule sameProjectAccess{
        permit
        condition stringAtLeastOneMemberOf(dataProject, userAssignedProject)
    }
}

Todo este espacio se llama Externalized Authorization Management. Puedes leer más sobre esto en el sitio web de Gartner.