[higgins-dev] Additional Auth Policy Topics

[David Kuehr-McLaren <dkuehrmc@xxxxxxxxxx>]

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