CHARON
The solution presented is based on work performed by the Organization for the Advancement of Structured Information Standards ( OASIS). The generic access control pattern presented in several OASIS standards related to security is the basis of ongoing work in OGC and similar working groups and research organizations. The ORCHESTRA project ( ORCHESTRA) has provided an initial Access Control Service Architecture that contributed vital ideas. An analysis of existing deficiencies resulted in the work presented here.
The CHARON Architecture realizes access control according to an abstract access control pattern. This pattern has been introduced as a data-flow diagram in the OASIS standard of the eXtensible Access Control Markup Language ( XACML (OASIS 2005) ) and applied, among other places, in the OGC Geospatial Digital Rights Management Reference Model ( GEO-RM (OGC 2006) ). It seizes on general ideas of policies as the basic mechanism to support the governance of service-oriented architectures. In ( SOA-RM 2006 ) a policy is defined as "the representation of a constraint or condition on the use, deployment, or description of an owned entity as defined by any participant". The abstract access control pattern explains a controlled call of a service operation request. It assumes that the rules that express the constraints and conditions defining "who may access which resource using which action" are recorded in an access control policy statement of the service. The access control pattern uses the following components:
The major tasks of access control comprise Profile Management, Identity Management, Authentication, Authorisation, Policy Enforcement and Policy Management. These tasks are supported by a set of services that are designed for an evolving heterogeneous environment and offer a high level of flexibility.
The major objective of profile management is to map a real world user to a representation in a service network (user registration). This representation is called a profile. A profile represents an acting entity which may be a human user or a software component like a service. In order to support multiple authentication mechanisms simultaneously and to keep authorisation-irrelevant information out of the access control mechanism, profiles and their identities are separated. The concept of an identity constitutes the key entity on which an authorisation decision is mounted, regardless of the underlying access control mechanism. In contrast to that, a profile provides information about the real world entity. The relation between profiles and identities is reflected in the profile and identity model specified in the Access Control Service Architecture section. The main functions covered by Profile Management are creation, update and deletion of instances of profiles and related information, in particular references to identities.
An identity is the core information required to realize access control. To interlink access rules and acting entities (subjects), access rules refer to identities and associated properties (attributes), issued by an IdP and verified by an AP. The main functions covered by Identity Management are management of identity related information, e.g. credential management, identity attribute management, and definition and management of identity groups.
According to SOA-RA 2008, authentication concerns the identity of the participants in an exchange. Authentication refers to the means by which one participant can be assured of the identity of other participants. The participants are profiles of real world entities that are represented by their identities. Authentication in the SAC Architecture is the process of verifying the identity of a certain profile. During the authentication process, an entity proves that it is allowed to act with the corresponding identity. This proof normally depends on the acting entity's credentials that can be, for example, what somebody has (e.g. a key or smart card), what somebody knows (e.g. a password), what somebody is (e.g. biometrical data), the place in which somebody resides (e.g. a certain computer) or the skills of somebody (e.g. a hand-made signature). The result of an authentication process is often called an assertion, a session, a ticket or a token. The issuer of an assertion (IdP) acts as the delegate for all service providers accepting assertions from this authentication authority. In this way an acting entity is not forced to present its credentials (e.g. a secret) at each service call and authentication can be done centrally. Assertions can be verified and are used for all actions that require proof of identity. In general, an assertion encompasses all identity related information that is required to perform an authorized request. Moreover assertions may contain information about the authentication provider, expiry date, etc. The main function covered by Authentication is therefore the verification of identity related information.
According to SOA-RA 2008, authorisation concerns the legitimacy of an interaction. Authorisation refers to the means by which an owner of a resource may be assured that the information and actions that are exchanged are either explicitly or implicitly approved. Authorisation is the process of determining whether an identity is allowed to have specified types of access to a particular resource. This is done by evaluating applicable access control information mainly consisting of an authorisation request and a policy. This information is used by the authorisation service to determine an authorisation decision. Usually, authorisation is carried out on the basis of successfully authenticated identities that are part of an authorisation request.
Policies or access rules can be expressed in many ways from simple access control lists to complex statements in policy languages like the OASIS eXtensible Access Control Markup Language ( XACML (OASIS 2005) ). The actual application of access rules is performed through the combination of Authentication and Authorisation and the enforcement of access control decisions.
Access control tasks include the provision of means to manage access rules. This is covered by Policy Management, which includes the following functions: creation, update and deletion of instances of policies, definition and management of policy templates for certain frequently used access control patterns, and distribution of policy templates.
The following figure illustrates how access control is accomplished through the interaction of services, each of which fulfils one or more of the access control tasks described above:
Part of the SAC Architecture, the profile and identity model (see Model for subject related information ), as one part of the overall SAC information model, plays a key role in the access control service architecture and enables the separation of concerns. As an example, the support of different authentication methods, without compromising the whole service architecture, is made possible due to the decoupling of profiles and identities as well as the management of identities in different instances of the Identity Management and Authentication Service, each possibly supporting a different authentication method.
This architecture has been developed as part of the SANY project. It is based on results of the ORCHESTRA project, which has provided a first step towards this development. As part of the SANY deliverables, all services are formally specified. The detailed specifications will be published during 2009. The SAC-enabled service interaction pattern between an arbitrary client and an arbitrary service is shown in the next figure.
The client and the services interact in the following order:
Note that the result (12) appears to the client as if it was calling a non-SAC-enabled service. This is one vital part of what we mean by being non-intrusive. SAC-enabling is done as an orthogonal task and service developers need not concern themselves with it.