ACWP Generic Model for AC

IHE White Paper on Access Control

Access Control System

Following the principles sketched above all security related tasks should be provided by a dedicated security architecture which is decoupled from the business architecture. Within the security architecture different subsystems are designated to different security services such as authentication, authorization, non-repudiaton, etc. An Access Control System (ACS) is a (logical) capsule around all authorization subsystem components that are (logically) linked with a node.

As shown in figure X each node that consumes or provides business functionality is bound to its local access control system. While the business services always communicate directly through request and response messages, their respective ACS might only be loosely coupled. E. g. a consuming service might request assertions on the user’s identity and role from its local ACS and sends them forward to the service provider as part of the request message. The service provider calls his local ACS for the decision on the acceptane of the request. Part of this call are the assertions that were received from the consuming business service.

Building Blocks

Each access control system makes use of several logical actors of a security policy management: PEP, PDP, PIP, and PAP. Each of these actors might appear in different instances (e. g. PIP for the management of subject attributes vs. PIP for the management of resource attributes) that could originate in different logical domains.

There is no fixed deployment of these actors among the participating nodes. A common ACS therefore is able to integrate components for the

• Management of policies and attributes
• Policy decision and policy enforcement
• Security token issuing and verification (for ACS federation)

Figure X shows the logical building blocks of a common ACS that correspond to these technical components.

These building blocks – which will be discussed in depth throughout the rest of this white paper - are:

• policy authority services for the management, selection, and activation of policies.
• attribute services for managing attributes an subjects, resources, etc. which have to be considered for the evaluation of policy rules
• security token services for the establishment of trust relationships to remote ACS and for the secure (with respect to integrity and authenticity) exchange of attributes and policies across domains.
• Policy enforcement and decision points which apply policies on business service requests. It is asumed that (at least on a model level) each request is mediated through the PEPs of the communicating nodes.

Access Control Domains

For discussing and evaluating access control solutions, a model is needed that is independent from the deployment of business services and the the distribution of ACS components among (physical) nodes. Therefore we use a model of domains where each domain is 'owned' by an authority that controls the objects and flow of control within the domain and its 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 domains’ ACS is derived from the common ACS model sketched above (Figure X).

The issuer of a request affecting a protected resource is located within the Context Domain. Since the service consumer is located at this domain, the assertion and message flow is controlled within that domain, too. The context is implicitely selected by entering it (e. g. opening a form in a hospital information system).

The context domain provides an attribute service for managing context attributes (e. g. current step in a medical workflow) and a policy authority for local policies (e. g. Separation of Duty). By entering the context, specific roles of the subject might be activated which are served by the subject domain’s ACS. In addition, a PEP/PDP for the enforcement of local policies (e. g. for constraints on role activation) resides here.

Authoritative identity sources with manageable subject attributes accomplish the basis for identity services in the Subject Domain. The subject domain hosts the identity provider (a dedicated Security Token Service) which is responsible for identifying and authenticating subjects by their claims, and encapsulating the respective assertions such that other STS can validate them. An additional attribute service renders subject attributes from directory services or other information systems.

The Resource Domain is characterized by the management of protected resources (e. g. medical database or EHR). Resources are marked with attributes that are considered as metadata. In order to restrict the access to protected resources, security and privacy policies might be rendered and evaluated by a resident policy decision point.

The linkage of the recource consumer and provider with their respective nodes’ PEP denotes that a complete mediation is enforced by either intercepting the access operation at the consumer’s or the provider’s side (or even at both sides) in order to decide on its acceptance with respect to the active policies.

Federated Healthcare Environments

The big challenge in healthcare environments is effective cooperation. Consolidated hospitals contribute to improved quality, strengthening of responsibilies, and decrease of costs. In general, a lot of use cases came up in the context of integrated care even in (inter-)national ehealth initiatives. A special characteristics of many scenarios is that co-operation among the participating enterprises is driven by on-demand, patient-group-specific, or disease specific issues. E. g. While hospital A might run a regional eye-care-network with hospitals B and C, it might co-operate with hospital B and nursing home D for the treatment of certain mental diseases.

The prerequisite for establishing such federated healthcare environments is mutual trust. Members of such federations produce a closed circle – the circle of trust. This requires more than simple node authentication (e. g. as provided by IHE ATNA), but verifable assertions on message level. For being able to cope with evolving sets of participants it is sufficient that the STS that establish the circle of trust and broker trust among enterprises are interoperabel and build upon well established standards.

Given a circle of trust, two major federation scenarios have to be considered:

• federation of resource domains: A context domain is able to request protected resources from multiple resource domains. Therefore the ACS at the context domain has to be able to share application semantics and policies with ACSs within multiple resource domains. This includes the ability of all attribute managing domains to provide attribute values in a way that can be understood by the domain that decides on the policy.
• federation of subject domains: A resource domain accepts requests from subjects that reside in different subject domains. By federating identities, subject domains are able to discover, exchange, and synchronize attributes that relate to the same subject.

Usually both scenarios are given at a time. E. g. in a P2P-network of co-operating hospitals, both subjects (identities) and resources might be federated in order to give requestors the impression to act on a single data base. ACS that communicate among each other through security token are implicitly federated and therefore best suited to provide access control even for highly distributed and ad-hoc established co-operation models.

IHE Profiles

---

Discussion

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

Change Requests

place your change requests here...