CHARON
In general the concepts presented can be used for arbitrary resource topologies. However, if we change our perspective to a viewpoint concerning the administration of, management of and responsibility for access control tasks we find that we have to consider disparate organisational units, so-called security domains. We define the term security domain as set of resources protected in accordance with a common policy. The fact that access control tasks can be spread over different jurisdictions indicates the need to support access control tasks for federated identities across multiple security domains. One of the key concepts is the Identity Provider (IdP) as the issuer of assertions, acting as delegate for all service providers accepting assertions from this authentication authority so that an acting entity is not forced to present its credentials (e.g. a secret) at each service call and authentication can be done centrally (for a particular security domain). The acceptance of assertions of a certain IdP implicitly defines a level of trust, in particular if assertions from more than one security domain are accepted. Part of the solution is the identity information model.
In the following a logical data model for the realisation of access control is presented. The section concludes with examples of how this model relates to prominent OASIS standards which are used in the access control service implementations. The Profile and Identity Model defines the basic concepts of "user" profiles and associated identities that support the tasks of the access control pattern introduced here. The following concepts are defined:
A profile is the abstract representation of an acting entity, e.g. a user or a service. To perform an authorised action (e.g. a service request) a user represented by his profile has to provide a proof of authenticity so that a service provider can decide whether the requested action is in line with the service provider's access policy. By introducing the concept of multiple identities for a single profile a user may present different identities, possibly authenticated with different authentication mechanisms, for different actions. By decoupling profiles from identities information not relevant for authorisation decisions can be kept away from the SAC mechanisms and requirements like Single-Sign-On can be easily supported. The separation of profiles and their associated identities reflects the real life situation in which a single user (a single profile) may have an arbitrary number of identities for particular purposes. A user may authenticate one or more of its profile's identities and thus accumulate access rights in disparate security domains (systems, networks and organisation).
Profiles are managed (created, deleted, etc.) using a Profile Management Service instance. Profile attributes are used to store arbitrary profile related information (e.g. first name, last name, address, e-mail). Identities are managed (created, deleted, etc.) using an Identity Management and Authentication Service instance. Identity attributes are used to store information that can be the basis for an authorisation decision. The Identity Management and Authentication Service acts as an identity provider.
The manner in which identity information is managed is up to the particular identity provider, as different authentication mechanisms (e.g. public key/secret infrastructures or login/password) require different identity related information. In this way the task "profile management" can act independently of the methods applied in the task "authentication" and vice versa. The attributes of associated profiles and identities may but need not be the same. No further assumptions about the structure of profile and identity attributes are made.
A group is modelled as a special type of identity that is composed of a set of identities. Group attributes are used to hold common properties of its members' identities. An identity that is a member of a group automatically inherits all identity attributes of that group as after login all related group identities are included in the SAML assertion (session information). Thus groups facilitate administrative operations which need to be applied to a number of identities of a single Identity Management and Authentication Service instance. A group can be treated as an ordinary identity by an instance of the Policy Management and Authorisation Service . Therefore, writing policies for groups does not differ from writing policies for any other identity. Management of groups is done according to the management of identities in instances of the Identity Management and Authentication Service .
Groups can only be defined on the level of a single Identity Management and Authentication Service instance, since the concrete representation of identities, and thus groups, may vary from instance to instance. To allow cross domain Identity Management and Authentication, and thus cross security domain enforcement of access rights, the concept of roles is used.
A role is an abstract concept (e.g. "administrator") that corresponds to a related policy. The usage of roles is a powerful yet simple way to facilitate large-scale authorisation management of complex systems. The general concept is applied in most databases and operating systems. Roles can reduce administration effort significantly, especially when similar access restrictions have to be enforced for many users of different organisations. As suggested by OASIS 2004 in this work roles are expressed as XACML Subject Attributes. In our approach a role is modelled as a special identity attribute named "role". If a mutual semantic agreement on the common role attribute exists among different security domains, the role concept allows the enforcement of access rights across all security domains regardless of individual identity representations or domain specific identity attributes.
Policies contain sets of rules to express access restrictions for particular resources. At the conceptual level no assumption about the policy language, namely 'how' a policy is encoded, are made. Policies hold the service side information for every access control decision.
In our architecture, the access control mechanisms rely on the usage of OASIS Security Standards. SAML (Security Assertion Markup Language) is used to encode identities and related information in a SAML Assertion. XACML (eXtensible Access Control Markup Language) is used to define access rules for the above mentioned identities.
SAML is a language used to encode security related information. We use SAML to encode Identity-related information. According to OASIS "SAML consists of building-block components [...]. The components primarily permit transfer of identity, authentication, attribute, and authorisation information between autonomous organizations that have an established trust relationship. The core SAML specification defines the structure and content of both assertions and protocol messages used to transfer this information. SAML assertions carry statements about a principal that an asserting party claims to be true. The valid structure and contents of an assertion are defined by the SAML assertion XML schema . Assertions are usually created by an asserting party based on a request of some sort from a relying party, although under certain circumstances, the assertions can be delivered to a relying party in an unsolicited manner. SAML protocol messages are used to make the SAML -defined requests and return appropriate responses. The structure and contents of these messages are defined by the SAML-defined protocol XML schema . The means by which lower-level communication or messaging protocols (such as HTTP or SOAP ) are used to transport SAML protocol messages between participants is defined by the SAML bindings. Next, SAML profiles are defined to satisfy a particular business use case, for example the Web Browser SSO profile. Profiles typically define constraints on the contents of SAML assertions, protocols, and bindings in order to solve the business use case in an interoperable fashion" ( OASIS 2006b ).
In our SAC Architecture, the SAML core (assertions and protocol) is used exclusively. No bindings or profiles have been defined as only core concepts of SAML have been used. Besides the SAML protocol schema for communication, SAML assertions issued by the Identity Management & Authentication Service acting as IdP contain the following core elements (see XML listings following):
The next figure indicates where SAML plays a role in relation to the abstract access control pattern.
In comparison to this figure request r, response p and ticket t are shown with their actual encodings.
According to OASIS "XACML is language for expressing access control policies. The language is used to standardise the process of access control management. Access control management consists of some or all of the following steps: writing, reviewing, testing, approving, issuing, combining, analysing, modifying, withdrawing, retrieving and enforcing of policies" ( OASIS 2005 ). XACML delivers a language to encapsulate security rules in policies in a standardised manner. If the same mechanisms of access control are used throughout the components of an information infrastructure, it is possible to manage the enforcement of policies in a consistent and to some extent interoperable way.
XACML uses the following concepts, described here in terms of slightly modified extractions from the XACML standard (OASIS 2005) : A rule is the most elementary unit of a policy. A rule can be evaluated on the basis of its contents and the request. The main components of a rule are a target, an effect and a condition. A rule target defines the set of resources, subjects, actions and environment to which the rule is intended to apply (it is possible to further refine the applicability by the target with conditions (see OASIS 2005 )). An XACML PDP verifies that the matches defined by the target are satisfied by the subject, resource, action and environment attributes in the request context, e.g. role. In summary, targets are used to determine which rules match the given request. The effect of a rule indicates the rule-writer's intended consequence of a "True" evaluation for this particular rule. Two values are allowed: "Permit" and "Deny". A policy is a container for rules and other information, e.g. a general policy target or a particular rule combining algorithm to support different matching policies for an authorisation request.
A Policy Decision Point acts as follows: after receiving a request the PDP matches the request against the policies to determine the policies to be considered, where matching simply means the evaluation of the target, which comprises functions on the attributes of the elements subject, resource, action and environment as described in the paragraph Rule. In case one of the targets matches, the effect is either "Permit" or "Deny". It is possible that there is more than one matching rule, and in this case the defined combining algorithm is used to provide an authorisation decision, e.g. if the combining algorithm is "Deny-overrides" then one occurrence of a "Deny" overwrites all occurrences of "Permit".
Next we use an example policy of a Sensor Observation Service (SOS) to illustrate how these concepts are used in the language. Translated to plain English the policy below specifies that for the service SoapBindingsSOSv3WS01 only those XACML subjects which are members of the group SOS User have read access. Further, the requested action must be getObservation. All of these properties are mapped in XACML policies via attributes, which are basically key value pairs. Due to this characteristic of XACML , it is possible to express arbitrary real world concepts as properties, e.g. roles, groups, company branch or department. Because there is a lot of boilerplate XML in the example code the interesting parts are marked in red boxes. For simplicity some parts of the policy document are omitted.
Next, we illustrate an example SOS Request. In plain English the request below wants to access the resource SoapBindingsSOSv3WS01. The requester is a member of the group SOS User. Further, the action element indicates that the requester would like to access the getObservation operation of the Sensor Observation Service.
The policy and the request taken together form the decision basis of a PDP for a given resource. There are only four possible PDP decisions:
"Permit" and "Deny" have already been discussed in the previous paragraphs. The value "Indeterminate" occurs if there is an exception during the evaluation of the request and no regular decision can be made. The decision "NotApplicable" indicates that there are no policies with a matching target/rule for the given request. In the example above an XACML PDP would decide that the requester is permitted to access the resource SoapBindingsSOSv3WS01 because a policy exists which addresses the resource in a target. Furthermore, the request has one subject which possesses the group attribute with the required value SOS User and the action attribute getObservation. Therefore the rule evaluates to the effect "Permit" and because of the fact that there are no further rules which could evaluate to "Deny" the resulting decision of the PDP is "Permit".