ACWP Generic Model for AC: Difference between revisions

Revision as of 04:37, 19 January 2009

PEP, PDP, PIP, and PAP are generic building blocks for an access control solution
each of these blocks might appear in different instances (e. g. PIP for the management of subject attributes vs. PIP fpr the management of resource attributes)

An Access Control System (ACS) is a (logical) capsule around all authorization subsystem components that are (logically) linked with a node
- Management of Policies and Attributes
- Policy Decision and Policy Enforcement
- Security Token issuing and verification (for ACS federation)
For discussing and evaluating access control solutions, a model is needed that is independent from the deployment of the ACS components at (pysiclal) nodes
Therefore we use a model of domains where each domain is autonomous and contains its own ACS. DOmains can be mapped onto nodes in a n:1 manner.
In the simplest case three domains are modelled: context domain, subject domain, and resource domain

each domain is 'owned' by an authority who controls the objects and flow of control within the domain
- context domain: request issuer as authority
- subject domain: subject as authority
- resource domain: resource owner as authority
each domain is suited to manage attributes and policies that are controlled by the domain's authority
an STS within each domain is used for the secure (with respect to integrity and authenticity) exchange of attributes and policies among domains

issuer of a request affecting a protected resource is located within this domain
- control of the assertion/message flow
- context is implicitely selected by entering it (e. g. opening a form in a hospital information system)
management of context attributes (e. g. current step in a medical workflow)
management of local policies (e. g. SoD)
activation of functional roles
PEP/PDP for the enforcement of local policies (e. g. for constraints on role activation)

place issues to be discussed among the editorial team here...

place your change requests here...

@@ Line 14: / Line 14: @@
 * In the simplest case three domains are modelled: context domain, subject domain, and resource domain
 [[Image:WPAC_Generic_Model_v01.png|640 px]]
+=== Management of Attributes and Policies===
+* each domain is 'owned' by an authority who controls the objects and flow of control within the domain
+** context domain: request issuer as authority
+** subject domain: subject as authority
+** resource domain: resource owner as authority
+* each domain is suited to manage attributes and policies that are controlled by the domain's authority
+* an STS within each domain is used for the secure (with respect to integrity and authenticity) exchange of attributes and policies among domains
 === Context Domain ===
-*issuer of a request affecting a protected resource
+* issuer of a request affecting a protected resource is located within this domain
-*management of context attributes
+** control of the assertion/message flow
+** context is implicitely selected by entering it (e. g. opening a form in a hospital information system)
+*management of context attributes (e. g. current step in a medical workflow)
 *management of local policies (e. g. SoD)
 *activation of functional roles
-*control of the assertion/message flow
 *PEP/PDP for the enforcement of local policies (e. g. for constraints on role activation)