ACWP Generic Model for AC: Difference between revisions
Jump to navigation
Jump to search
| Line 2: | Line 2: | ||
== Generic Model for Access Control == | == Generic Model for Access Control == | ||
* 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) | |||
===Access Control Systems=== | ===Access Control Systems=== | ||
* 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 | |||
[[Image:WPAC_Generic_Model_v01.png|640 px]] | [[Image:WPAC_Generic_Model_v01.png|640 px]] | ||
* | === Context Domain === | ||
* | *issuer of a request affecting a protected resource | ||
**control of the assertion/message flow | *management of context attributes | ||
*Domain 2: Subject Domain (in XSPA part of the issuing domain) | *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) | |||
=== Domain 2: Subject Domain === | |||
* (in XSPA part of the issuing domain) | |||
* Subject authentication | |||
* Management of subject attributes | |||
=== Domain 3: Resource Domain=== | |||
*management of protected resources (e. g. data base) | |||
*management of resource attributes | |||
*management of resource security policies | |||
*policy enforcement and policy decision | |||
<hr> | <hr> | ||
Revision as of 16:14, 17 January 2009
IHE White Paper on Access Control
Generic Model for Access Control
- 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)
Access Control Systems
- 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
Context Domain
- issuer of a request affecting a protected resource
- management of context attributes
- 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)
Domain 2: Subject Domain
- (in XSPA part of the issuing domain)
- Subject authentication
- Management of subject attributes
Domain 3: Resource Domain
- management of protected resources (e. g. data base)
- management of resource attributes
- management of resource security policies
- policy enforcement and policy decision
Discussion
place issues to be discussed among the editorial team here...
Change Requests
place your change requests here...