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 acceptance 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 resource 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 cooperation 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. Other partners might join these networks on demand.

Dynamic networks like these where each partner is in control of its own resources and where mutal trust – e. g. in authenticated itentities of other partners - is established when needed, are called fedarations. By their ability to broker trust the participating partners form a »circle of trust« that allows for security token to be issued and consumed by all partners.

With respect to health information exchange, 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 cooperation models.

IHE Profiles

Many of the ACS building blocks are already covered by existing IHE profiles (figure X).

The Cross-Enterprise User Assertion (XUA) integration profile provides mechanisms to exchange authenticated subject information across domain boundaries. It is therefore well suited for connecting the subject domain to the circle of trust. By combining XUA and Kerberos-based Enterprise User Authentication (EUA) an already IHE compliant enterprise can run its own identity provider using existing technology. The Personnel White Pages (PWP) integration profile defines how organizations might maintain attributes describing their personnel based on common LDAP technology. By either integrating this information into an XUA or by providing it to external users through security tokens (e. g. using an STS-safeguarded policy information point) the subject domain’s required functionality can be provided by already existing IHE profiles.

The management and provisioning of attributes on patients is subject to the PIX and PDQ integration profiles. Depending on the deployment and the application semantics, the respective attribute services can either be located with the context domain, the resource domain, or a dedicated patient domain (see chapter 4).

The Basic Patient Privacy Consent (BPPC) integration profile describes how XDS registries and repositories can be used for maintaining privacy policies. This allows for setting up a policy authority within the resource domain. By encapsulating this functionality by a security token service, privacy policies can even be exchanged in a secure manner across domain boundaries. XDS registries are designated for the management and provisioning of resource attributes and as such provide the functionality of an attribute service. Using existing profiles for the management of policies and resource attributes at the resource domain and for the trusted exchange of subject attributes among domains, even rather complex access control scenarios can be implemented. The major white spots not recently covered by IHE integration profiles are PEP/PDP and policy authorities which are decoupled from the resource managing systems. Possibles strategies for evolving in this direction are discussed in section 4.x of this white paper.

---

Open Issues

Figure on IHE profiles: PHR must be changed into XPHR Joerg.caumanns 20:58, 19 February 2009 (UTC)