[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[higgins-dev] Additional Auth Policy Topics


Jim,

Thanks for the auth call today.  Good stuff.

Some other ideas I have on the access subject:

One item/requirement missing from the from the minutes:   Not all access to the context will have a subject id or Entity Identifier from any context (e.g. user authentication validated with idemix; helpdesk admin accessing a CRM db).  

->AccessControlPolicy

The subjectEntity used to evaluate an AccessControlPolicy needs to map to more than entities and groups of entities. The AccessControlPolicy needs to allow relationships (e.g. isManager, isFriend) and conditions (e.g. hasPremiumMembership, isOlderThanTwentyOne, wasTwoFactorAuthenticated).  I think the access object needs to contain Conditions, Resources, Permissions. Consider the case where idemix provides the verifies the claims and there are only attributes available. There may still need to be a subjectEntity built (what I was calling a pseudoEntity) that represents the idemix verified claims. This subjectEntity will either have a mapped EntityIdentifier, or no EntityIdentifier.

Mapping a specific subjectEntity is a type of condition: isEntityIdentifier=http://mycontext/kuehrmc (maybe its "hasEntityIdentifier"); or isMemberOf=http://mycontext/admingroup.   Not all CPs would need to support all or any of the conditions. Perhaps conditions, like schema, are defined by the CP with common profiles or best practices (e.g. most CPs will support isEntityIdentifier and isMemberOf).  Need to accommodate conditions for "anonymous", "anyAuthenticated", and "anonymousAuthneticated"


->Scaling (both human and runtime)

For administration scaling, the policy object needs to allow multiple resources, multiple permissions, and multiple subject entities in a policy.   Expanding on the AccessControlPolicy suggestion above, an policy would consist of

     -- Conditions or Collection of Conditions (including boolean expressions like isDoctor and IsMemberOf=RexHospitalGroup and hasValidBoardCertificate)
     -- Resources or Collection of Resources (could be a group or hierarchy as defined by the CP, see below)
     -- Permissions or Collection of Permissions (policy can include the explicit permissions or point to an collection of permissions)

The "Collection" could be a group or it could be a point in a relationship hierarchy. Access control administration is often scaled by using hierarchies of resources and/role hierarchies of roles. Policies apply to points in the hierarchy. This allows the administration scaling by reducing the number of policies required and the ability to delegate policies for portions of the resources and/or roles. From a runtime perspective, the hierarchies allow for efficient run time evaluation.  The idea of Collections also allows the separation of the administration of permissions (access roles), principals (business/social roles), and resources.

A note about the "deny" bullet in the minutes.  The ability to have a "deny" permission implies that the resources and roles can be organized hierarchically.  At its simplest, the hierarchy can be flat (one level), where a "grant" policy us attached to the root and a "deny" policy attached to individual resources.  

Other thoughts?

David

David Kuehr-McLaren
IBM Tivoli Security
919.224.1960