A Service Access Control Framework for a Sensor Service Architecture

Proceedings of the 44th Hawaii International Conference on System Sciences - 2011

A Service Access Control Framework for a Sensor Service Architecture Ralf Denzer, Sascha Schlobinski, Reiner Güttler Pascal Dihé, Martin Scholl, Sebastian Puhl Environmental Informatics Group Goebenstr. 40, 66117 Saarbrücken, Germany [email protected]

Abstract Sensor and earth observation data are becoming more and more available through service networks. In order to provide operational services, reliable and easy to use mechanisms for security, authentication and distributed access control are vital for service providers when offering their services. This paper describes a Service Access Control (SAC) framework which was developed as part of the SANY project, a project of the 6th European Framework Program (FP6) which has developed a reference model and service architecture for sensor service networks. The result of this work is the CHARON Service Access Control Framework, which aims at overcoming the major problems identified in the analysis. This paper describes the overall functionality of the SANY SAC framework, its implementation CHARON and its key components.

1. Introduction European, national and regional initiatives for spatial data infrastructures (SDI), most notably INSPIRE [1] share the vision of a virtual marketplace where information and services are available under a multitude of business models. To be able to create such a marketplace the underlying infrastructure has to deal with property rights, licensing Models and a concept how the access to resources can be regulated. For obvious reasons, security and access control concepts and technologies are important components of this vision. For instance, INSPIRE states no direct requirement for security and access control of resources [2,3]. However the directive explicitly allows the licensing of and/or payment for spatial data sets (Chapter V Article 17.3) and therefore implicitly require considering access control issues in the implementation of the SDI.

The INSPIRE Network Services Architecture [2], the technical basis for inter-operability in INSPIRE, states that “INSPIRE geo rights management services (GeoRM) are envisioned to manage different kinds of rights (legal, business contracts, access keys) between an application (e.g. a geoportal) and the INSPIRE infrastructure if needed. Examples for GeoRM service functions are authentication, authorization, pricing, billing and licensing. The implicit functions of the GeoRM services are orthogonal to the other INSPIRE service types. Therefore GeoRM services are also called “Horizontal Services”. All or most of these aspects need to be considered for all kind of the INSPIRE services”. This means that potentially all or at least a large number of INSPIRE-related services implemented throughout Europe may require this functionality. There are several ways of how to classify the related tasks. For the purpose of this paper, the best way to subdivide the involved activities is to consider the following major areas: • Security • access control • rights management In this classification, security deals with the protection of message transport and services against intentional misuse (break-in, attacks and so forth) and unintentional misuse (i.e. faulty software). Access control deals with decisions whether some entity (user or software) is granted access and how. Rights management deals with licenses, contracts, billing and so forth. The purpose of the above classification is to identify those parts of the overall picture which are absolutely essential for an access controlled SDI, i.e. those parts which are required and not optional for any kind of access controlled SDI.

1530-1605/11 $26.00 © 2011 IEEE

1


Consumer

Security Access Control

Rights Management

Resource

Figure 1. Required and optional (dotted) parts of an access controlled SDI Every access controlled SDI obviously needs access control mechanisms when a consumer wants to access a resource (Figure 1). The more advanced levels of rights management (licensing, billing etc) may or may not be needed. For instance, there could be a provider (and there are such providers) whose policy it is to make all of their accessible resources available for free. For such a provider, even thinking about licensing would be a waste of time. The same is true for security aspects. Depending on the resource and on the provider, security might be of high or low priority, or not needed at all with the exception of standard mechanisms which are applied everywhere today. The access control of resources is therefore the minimal requirement for any SDI. Resources can be classified as data resources and computational resources. However, in the world of service oriented architectures (SOA), which is one of the dominant architectural patterns today [4,5], the access control of both types of resources boils down to protecting services, therefore the term Service Access Control (SAC). Without SAC, large-scale SDI will not be possible as there are always resources which need protection for a variety of reasons. As part of the SANY project [6] the authors have developed a generalized architecture and a software framework for Service Access Control (named CHARON). The architecture applies a well known architectural pattern, and comes with open public specifications of the required SAC services. The software framework delivers implementations of the SAC services according to these specifications, as well as tools which allow developers to enable their services with access control functionality. CHARON solves a

number of problems which were identified early in the project, and makes propositions how to close certain gaps in the state-of-the-art. The purpose of this paper is to describe the results of CHARON, why CHARON was built as it was, and which gaps in the state-of-the-art were approached by our research. The authors follow the explicit goal to describe the overall problem and solution in a way which is also readable for those who live outside the “security / access control world”.

2. Service Access Control Access control (Service Access Control in a service-oriented architecture) is understood as the ability to permit or deny use of a particular resource by a particular entity. In general, access control mechanisms ensure that only authorized entities may access resources using well defined methods that comply with the access control policy of the system. Therefore a access control architecture manages the authorized use of resources in a system. A service access control architecture (SAC Architecture) manages the authorized use of services and their resources in a SOA. In contrast, information system security is the embracing concept which includes access control and cryptographic measures (encryption, signatures, security protocols and so forth) to satisfy certain security requirements like integrity and confidentiality, or the ability to counter attacks and threats. Overall models to describe all aspects and dimensions of information system security can be found in a number of existing security frameworks, for instance published in [7] and [8]. The provision of an overall model and architecture for security, access control and rights management for each and every type of SDI is out of the scope of the presented work. On the security level, specific threats require specific counter measures which in most cases cannot be handled on an abstract architectural level (see for instance a threat analysis of the OGC SWE services in [9]). The requirements developed in the SANY project clearly show a priority of basic access control over security and advanced rights management. Solving the access control aspect of the overall system security has the largest impact for the types of service networks addressed by SANY. As a consequence, the specifications and the software developed as part of CHARON focus on those issues which can be developed independently of the underlying and case specific or even service specific security requirements. More advanced rights management concepts like those in the GeoDRM [10] are also not considered. The discussion in this paper requires a clear understanding

2


of the underlying terminology, which is summarized in Table 1. It is also important to understand the basic tasks of access control. These tasks comprise Identity Management, Profile Management, Authentication, Authorisation, Policy Management and Policy Enforcement. In a SOA, these tasks need to be supported by a set of services. An identity is the core information required to realize access control. The main task covered by Identity Management is the management of identity related information, e.g. credential management, identity attribute management, definition and management of identity groups. Profile Management maps real world users to their representation in a service network (user registration), which is called a profile. A profile represents the footprint of 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 authorisationirrelevant information out of the access control mechanism, profiles and their identities (i.e. principals) are usually 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 main functions covered by Profile Management are creation, update and deletion of instances of profiles and related information, in particular references to identities. Authentication refers to the means by which one participant can be assured of the identity of other participants [11]. The main function covered by authentication is therefore the verification of identity related information. 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 handmade signature). The result of an authentication process is often called an assertion, a session, a ticket or a token. The issuer of an assertion 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. Authorisation is concerned with 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 access control information, which mainly consists of an authorisation request and an authorisation 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. Finally, in order to carry out access control tasks, it is necessary to express access control rules and to provide the means to manage such rules. This is covered by Policy Management, which comprises the creation, update and deletion of instances of policies, the definition and management of policy templates for frequently used access control patterns, and the distribution of such policy templates. Policy Enforcement is the process of mapping authenticated identities, policies and requests into an authorisation decision.

3. Existing solutions Research and development in SOA access control and security have provided a large number of specifications as well as both free and commercial tools to equip SOA-based applications with access control. In commercial SOA-based applications, security measures are often undertaken on a case by case, possibly requirement driven basis, resembling the process of actual service and message specification and implementation. The volume of existing security- and access control-related specifications, approaches and architectural patterns for SOA is immense. In terms of standards, both OASIS and W3C need to be mentioned. In OASIS, WS-Security [12], WS-Trust [13], SAML [14] and XACML [15] are prominent. In W3C the Web Services Policy Framework [16] provides a general purpose model and syntax to describe and communicate the policies of a Web service. The WS-I Basic Security Profile (BSP), backed by a number of major companies, is a guide for ensuring secure, interoperable Web services. The OASIS standards body has particularly undertaken efforts to provide standards for web service security at the message level, supporting the design and implementation process for each individual solution and leaving an abundance of choices to the developer. When dealing with environmental information systems, service specifications of the Open Geospatial Consortium (OGC) are the de-facto generic standard which cannot be ignored because they are the baseline for spatial data and services. The existence of such standard geospatial services drives the requirement for security approaches, which are equally interoperable, which work in conjunction with all standard OGC

3


Term

Explanation

Sour ce

Access control

Ability to enforce a policy that identifies permissible actions on a particular resource by a particular subject. An assertion is a proposition that is held to be true by a stakeholder. It is essentially a claim about the state of the world. Note: In the context of SAML the term Assertion is used as a synonymous expression for Ticket. 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. Information used as proof of Identity (e.g. a password). Note: during an Authentication process, credentials are presented to an Identity Provider to obtain related identity information (Ticket). The collective aspect of the set of characteristics by which a thing is definitively recognizable or known. Note: In the SANY project, the term Identity refers to a concept that is used to recognize a subject. A subject may have several identities. Entity that issues identity information and possibly acts as authentication authority. Representation of a constraint or condition on the use, deployment, or description of a resource

SANY 2009

Assertion

Authentica tion

Credential

Identity

Identity Provider Policy

Profile Security Domain Session

Information (set of attributes) describing a subject. Set of resources protected in accordance with a common policy Temporarily valid ticket

Subject

Abstract representation of a user or a software component in an application.

Principal Ticket

See Identity Information issued by an identity provider to be used as proof of identity when accessing a resource

SOARA, 2008

SOARA, 2008 SANY 2009

(Dictio nary, 2004)

SANY 2009 derived from SOARM, 2006 SANY 2009 SANY 2009 SANY 2009 OGC 07097; RMOA 2007 SANY 2009

Table 1. Access Control Base Terminology services, and which do not rely on individual design decisions of particular projects. As security is a topic that in most cases is orthogonal to the geospatial context, OGC’s security activities are often geospatial extensions of existing solutions. OGC has undertaken considerable effort to investigate various aspects of security and access control for OGC, for instance By defining

GeoXACML, which provides spatial data types and spatial authorization decision functions, which can be used for additional spatial constrains for XACML based policies. Similarly, GEO-RM aims at digital rights enforcement of spatial resources. Several R&D and standard specifications include proposals for architectural patterns, like the Gatekeeper Metaphor (GEO-RM), or the abstract interaction pattern of OASIS, which is the basis of the presented work, the GDI-NRW pattern to secure OGC-based services [17] or the ORCHESTRA UAA services [18]. What is missing is a general architectural approach how to security-enable OGC and related web services, including all SWE services, in a non-proprietary way. One major missing piece is that general specifications of SAC on a service level do not exist. There are numerous specifications and standards for individual pieces of the problem, in particular for the encoding of messages, policies and rights, but no standard specification of SAC Services exist. This leads to the situation in which SAC is implemented for each individual case in an individual fashion, or – even worse – that proprietary extensions are used, which contradicts the notion of a standard. It will not be possible to accept either approach in the context of SDI’s like INSPIRE.

4. The SANY SAC Architecture 4.1 Design goals The requirements of the SANY SOA have been derived from a number of practical sensor-related use cases of the SANY project. From the fact that SANY is a SOA immediately follow certain SOA architecture properties, like loose coupling. The SANY requirements also include requirements for access control. These requirements, taken together with the deficiencies identified in the state-of-the-art, have driven the design goals of the SANY SAC Architecture as follows: • It shall be flexible. This means that the SAC must be applicable for arbitrary services in a large variety of use cases. From this concludes in particular that just “adding access control” to a fixed number of services (for instance the OGC standard services or the OGC SWE services), as it is done in some proprietary cases, will not be sufficient. This also means that different access control mechanisms shall be supported, like PBAC (Policy Based Access Control, [19]), IBAC (Identity Based Access Control, [20], RBAC (Role Based Access Control, [21]) and ABAC (Attribute Based Access Control, [22]). Flexibility also requires backwards

4


compatibility, in particular where controlled and un-controlled components (services as well as clients) may still reside in parallel in an SDI. • It shall be scalable. This means that an arbitrary number of SAC services can control an arbitrary number of protected services, for management, performance or organisational reasons. • It shall be non-intrusive. This means that the implementation of access control for existing or new service networks shall not come with the need of heavy (re-) engineering and that the SAC shall blend in easily in the architecture. It also means that not every software engineer involved in building a SOA must be a specialist in access control / security related topics, which are not trivial. • It shall be based on open standards and be non-proprietary. This is an absolute requirement in order to achieve inter-operability and long-term sustainability of SDI’s. It is also the only way to implement in a cost-efficient way by being able to use existing building blocks. • It shall be extensible. This means that the SAC Architecture implemented by SANY must be capable to incorporate other or new access control and security features seamlessly, or: although the SANY SAC focuses on the “required” part in Figure 1, it must be capable to support the optional parts, for instance by adding message security of different types, depending on concrete security requirements of a particular SDI. The SANY SAC Architecture presented in this chapter and the CHARON SAC framework (its implementation) presented in the next chapter follow these design goals. 4.2. Design options Several overall design options (architecture patterns) for the SAC Architecture were discussed. There is no consistent terminology for these patterns in the literature. 4.2.1 Meta model We call the first option the Meta Model Approach. In this approach every service has to handle access control, which is done by adding security and access control information to the service signature (for instance information like session parameters). Each

service implementation needs to be outfitted with access control and every developer of every accesscontrolled service needs to handle access control issues in addition to their regular work. This has severe disadvantages. First, every developer needs to become an SAC specialist, which is not going to happen. Secondly each service needs to handle its own SAC information which requires heavy and duplicated engineering, and which is prone to creating heterogeneous islands of different SAC approaches. The latter can be avoided if the overall SDI is defined by a service meta model (like for instance in [18]), which at least enforces a uniform SAC service interface and information model. This design option has been discarded because it does not conform with the design goal to be non-intrusive. 4.2.2 Generic proxy The second design option is the Generic Proxy Approach. In this approach, a proxy service shields arbitrary services through a generic interface where the actual service request is transmitted as the payload of a generic operation. This leads to the famous generic service interface with one method called “execute()” or “doServiceRequest()”. The advantage would be that the proxy would contain the SAC-related functionality which could be solved independently once. In this approach the actual service interface is no longer visible, which hinders such activities as discovery, and induces adaptations to client applications like agents for harvesting. Every software designer who has ever used such interfaces knows about the problems of pushing all the knowledge about the service interface into the service client. This approach does not conform to our design goal to be non-intrusive, but the intrusion is here also, maybe mainly, on the part of the service client. The approach is also not scalable because there are implicit relationships between clients and services. 4.2.3 Transparent proxy The third design option is the Transparent Proxy Approach. In this case, a service side facade (transparent proxy) is provided, which mimics the actual service interface. Such a proxy can be generated from any formal service description (e.g. WSDL) in combination with a generic access control component (a Generic Proxy). Obviously, the major drawbacks of a pure Generic Proxy are eliminated, as the Transparent Proxy’s interface looks like the original services interface. Again the advantage is that the proxy would contain the SAC-related functionality which could be implemented once. In addition, the Transparent Proxy Approach also has the advantage of providing backwards compatibility, which means that uncontrolled clients are still able to communicate with

5


a controlled service and controlled clients can communicate with uncontrolled services. 4.3. SAC delegation Using a proxy allows to delegate the SAC implementation and SAC decisions of every service in an SDI to a third party (or several third parties if needed), which is the major advantage of the approach, as it is non-intrusive and not every service developer needs to be concerned with SAC implementation. SAC is implemented once, and is re-used by services which need to be access controlled. From this starting point here, many options are opened up in the actual SAC design. Figure 2 shows an abstraction of an architecture pattern commonly found in distributed access control.

Access Control Markup Language (XACML) and applied, among other places, in the OGC Geospatial Digital Rights Management Reference Model. It seizes on general ideas of policies as the basic mechanism to support the governance of service-oriented architectures. In [11] 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 in Figure 3 (a more detailed version of Figure 2) uses the following components:

The service and the request issued by a requester (the subject) are connected through a so-called Policy Enforcement Point (PEP), which enforces the access control policies when accessing the service. The PEP uses two helpers, the Authentication Provider (AP), which authenticates the subject, and the Policy Decision Point (PDP), which provides the authorisation decision. Only if a subject is properly authenticated, and if that subject is authorised to access the service, will the PEP grant access to the service. Note that the block “Service” combines the service proxy (or the facade) solving the SAC as well as the uncontrolled service.

Figure 3: Abstract Access Control Pattern (t denotes a ticket, r denotes a request, p denotes a service response)

Figure 2. Architecture pattern common to SAC delegation 4.4. The SANY SAC abstract access control pattern The SANY SAC Architecture implements an abstract access control pattern which we found most practical to be used in a service-oriented approach. This pattern has been introduced as a data-flow diagram in the OASIS standard of the eXtensible

• • • •

The Subject is the requestor of the service operation. It represents the acting entity, for instance a user The Identity Provider (IdP) issues a ticket as proof of successful provision of a subject’s credentials. The Authentication Provider (AP) has the task of verifying issued tickets. The Policy Enforcement Point (PEP) receives a service operation request, enforces

6


• • •

the access control policy of the service and forwards the service operation request to the protected service. The Policy Decision Point (PDP) responds to an authorisation request with an authorisation decision. The Policy Information Point (PIP).adds context information that is another input for a decision. The Policy Administration Point (PAP) provides an interface to perform administrative tasks on the policy level and gives gives access to the service’s policy information.

This pattern is completely independent of the underlying systems design approach, but as it decomposes the functions of access control, it is particularly useful to be implemented in a SOA. It has been implemented as part of the project in the CHARON framework, which provides access control as through a number of services.

5. The CHARON Framework The CHARON framework [23] is based on previous work in the context of the ORCHESTRA project [24], which provided both specifications and implementations of the so-called UAA services (User Management, Authentication and Authorisation Services), which were a predecessor of the work presented here. The ORCHESTRA UAA Services did not meet some of the requirements described in chapter 4. In particular they were not non-intrusive and the SAC messages were not standards-based. This is why the work was extended in the SANY project. CHARON implements the access control pattern of figure 3 and follows the idea of Security as a Service where “security is realized through decoupled, composeable services” [25]. The framework satisfies all SAC requirements stated in chapter 4 and consists of the following components: • The specification of an SAC Information Model including a general profile and identity model • A choice of standards and encodings for message transport • Specifications for the security services • Implementations of the security services • A GeoXACML PDP • A proxy generator tool • An administration client • Scripts to create a database back-end for the services

A description of the overall functionality and concepts can be found in [26]. Specifications and additional information regarding the software can be found at the CHARON website [23]. Although relatively simple, the SAC Information Model plays an important role in the architecture. It is for instance possible to support of different authentication methods without compromising the whole service architecture. This is done by decoupling of profiles and identities and the management of identities in different instances of the Identity Management and Authentication Service (see below), which can support different authentication methods. The standards chosen for message transport and encodings of SAC-related information are the currently available standards, i.e. • The Simple Object Access Protocol (SOAP 1.2) • The Security Assertion Markup Language (SAML 2.0) for the exchange of authentication and authorization assertions between communicating parties • The eXtensible Access Control Markup Language (XACML) as a language to express security rules in policies in a standardised manner • The Geospatial XACML (GeoXACML) as a geospatial extension of XACML which allows the definition of spatial constraints in XACML based policies The service specifications of the SANY SAC services are also available at the CHARON web site. The service implementations are factored as follows (figure 4): • The Profile Management Service (# 1, figure 4) manages profiles and their relations to identities. • The Identity Management & Authentication Service (# 2, figure 4) is responsible for the management of identities, their authentication and the management of credentials. An instance of the service acts as both authentication provider (AP) and identity provider (IdP). • The PEP Service (# 3, figure 4) handles the necessary interaction (authentication & authorisation) to obtain the required access control decision and is independent of the controlled service. • The Policy Management and Authorisation Service (# 4, figure 4) supports the management of policies, acting as policy administration point (PAP) .Moreover, as an instance of the authorisation service interface it acts as the policy decision point (PDP).

7


The software includes an implementation of a GeoXACML PDP which is the first a freely vailable, non-proprietary PDP implementing GeoXACML. The original (uncontrolled) service is mimicked by a service proxy. This proxy is generated by a proxy generator tool, which takes the WSDL interface description of the original service and generates the proxy service. For all services there is a SQL database back-end to persistently hold the SAC information. CHARON provides scripts to create these databases. Finally, an administration client is available to maintain the SAC information in the SAC services deployed.

Components of a rule are a target, an effect and a condition. The target defines the set of resources, subjects, actions and environment which are the basis to evaluate the rule. The effect of a rule indicates the consequence of a true evaluation for the rule. Two values are foreseen for the effect: "Permit" and "Deny". The condition is a formal statement which allows a processor to evaluate whether the rule is true or not. A policy is simply a container for rules and other information, for instance a general policy target or a particular rule combining algorithm to support different matching policies for authorisation requests. Policies expressed in XACML are used by the CHARON PDP to come to a decision whether access is granted or not. The PDP verifies that the matches defined by the target are satisfied by the subject, resource, action and environment attributes in the request context. When receiving a request, the PDP matches the request against the policies, and 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. In this case a combining algorithm is used to provide an authorisation decision. For instance, if the combining algorithm used is “Deny-Overrides”, then one occurrence of a “Deny” overwrites all occurrences of “Permit”. In Figures 5 and 6 we show an example of a policy, and a request, for a Sensor Observation Service (SOS).

Figure 4: Access control as a service

6. Standards-based policy encoding As stated earlier in this paper it was a requirement as well as a design goal that the SAC be nonproprietary, i.e. that the implementation is as much as possible standards-based. Consequently this must also be the case for the exchange and encoding of session and policy information. SAML and XACML are used for this purpose. In order to achieve the goal of maximum flexibility in access control approaches (RBAC, ABAC and so forth), it is particularly important that the policy encoding is flexible enough. It this chapter we give an example which illustrates that this is the case. XACML uses the following concepts: a rule is the most elementary unit of a policy. A rule is evaluated based on its content and a request to a resource.

Figure 5: Example policy

8


Translated to plain English the policy in Figure 5 specifies that for the service SoapBindingsSOSv3WS01 only members of the group SOS User have read access and that the requested action must be getObservation. All these properties are mapped in XACML policies via attributes, which are key-value pairs. Due to this characteristic of XACML, it is possible to express arbitrary real world concepts as properties, e.g. roles, groups but also concepts like “company branch” or “department”. In plain English the request in Figure 6 specifies that the requester 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.

“Indeterminate” occurs if there is an exception during the evaluation of the request and no regular decision can be made. The value “NotApplicable” indicates that there are no policies with a matching target/rule for the given request.

7. Conclusions The SAC Architecture presented in this paper has been developed based on real world access control requirements of sensor network applications. It uses standards wherever possible and provides a new set of specifications of access control services implementing a well-known access control pattern. It hereby closes a gap in the state-of-the-art towards “access control as a service” in the context of spatial applications. The CHARON framework provides specifications, service implementations and tools necessary to equip service infrastructures with access control mechanisms, with minimal effects on the actual service interaction. A flexible SAC information model supports several access control paradigms which enables designers to cope with arbitrary requirements for the entity on which an access control decision is made. It is particularly important that application service developers do not need to become deep experts in SAC and that the approach ensures backwards compatibility, which means that an unsecured components can still communicate with secured components. In compliance with work of the OGC Security and DRM working groups, the SAC Architecture incorporates OASIS standards into the solution. Tangible results of this work are a set of specifications, service implementations and tools which can be used to implement distributed service access control in service networks. The work presented closes existing gaps of service based environments.

8. Acknowledgements Figure 6: Example request The policy and the request taken together form the decision basis of the PDP. In this example the PDP will decide that the requester is granted access to the resource SoapBindingsSOSv3WS01, because a policy exists which addresses the resource in a target. Furthermore, the request is made by a 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 other rules which could evaluate to "Deny", the resulting decision of the PDP is "Permit". For completeness, note that a PDP can also evaluate a request to the results “Indeterminate” and “NotApplicable”. The value

SANY is an Integrated Project (contract number 0033564) co-funded by the Information Society and Media DG of the European Commission within the RTD activities of the Thematic Priority Information Society Technologies”. The authors wish to thank the SANY Consortium for their valuable collaboration.

9. References [1] INSPIRE , Official Journal of the European Union, DIRECTIVE 2007/2/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE), 25-04-2007, eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2007:10 8:0001:0014:EN:PDF

9


[2] INSPIRE 2007b, INSPIRE Network Services Architecture V2.0, 17-12-2007, inspire.jrc.it/reports/ImplementingRules/network/D3%205_I NSPIRE_NS_Architecture_v2.0.pdf [3] INSPIRE 2008, INSPIRE Network Services Architecture V3.0, 19-07-2008, inspire.jrc.ec.europa.eu/reports/ImplementingRules/network/ D3_5_INSPIRE_NS_Architecture_v3-0.pdf [4] Arsanjani A., Service-Oriented Modeling and Architecture, IBM developer works, 2004 [5] Usländer T. (ed.), Reference Model for the ORCHESTRA Architecture (RM-OA Version 2.1), OGC Best Practices Document, portal.opengeospatial.org/files/?artifact_id=23286, 2007 [6] Havlik D., Introduction to SANY (Sensors Anywhere) Integrated Project, ENVIROINFO 2006, Shaker, Graz, Austria, p.541-546, 2006, see also: sany-ip.eu [7] ITU-T 2003, ITU-T Recommendation X.805 - Security architecture for systems providing end-to-end communications (10/2003), http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-RECX.805-200310-I!!PDF-E&type=items [8] CERT 2009 , Octave, 2009-12-06, [9] Matheus A. (Ed.) Open Geospatial Consortium Inc. (OGC 08-176r1): OWS-6 Secure Sensor Web Engineering Report, Version 0.3.0, Date: 2009-07-29, http://portal.opengeospatial.org/files/?artifact_id=34273 [10] Vowles G. (Ed.) Open Geospatial Consortium Abstract Specification 06-004r4: The OpenGIS Abstract Specification Topic 18: Geospatial Digital Rights Management Reference Model (GeoDRM RM). Version: 1.0.0. 2006-12-29 [11] SOA-RA 2008, OASIS Reference Architecture for Service Oriented Architecture Version 1.0 Public Review Draft 1, 23 April 2008 http://docs.oasis-open.org/soa-rm/soara/v1.0/soa-ra-pr-01.pdf [12] OASIS Web Services Security: SOAP Message Security 1.1 (WS-Security 2004), OASIS Standard Specification, http://www.oasisopen.org/committees/download.php/16790/wss-v1.1-spec-osSOAPMessageSecurity.pdf [13] OASIS WS-Trust 1.3, http://docs.oasis-open.org/wssx/ws-trust/200512/ws-trust-1.3-os.doc [14] Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V1.1, http://www.oasisopen.org/committees/download.php/3406/oasis-sstc-samlcore-1.1.pdf [15] XACML Profile for Role Based Access Control (RBAC), Committee Draft 01, 13 February 2004, http://docs.oasis-open.org/xacml/cd-xacml-rbac-profile01.pdf [16] Web Services Policy Framework (WSPolicy) March 2006 Version 1.2, http://download.boulder.ibm.com/ibmdl/pub/software/dw/spe cs/ws-polfram/ws-policy-2006-03-01.pdf [17] Drewnak J. (Ed.), GDI NRW Geodateninfrastruktur Nordrhein-Westfalen Testbed II, Februar – Dezember 2002 Dokumentation Version 1.0, Web Security Service, 2002 [18] Usländer T. and Denzer R., Requirements and Open Architecture for Environmental Risk Management

Information Systems,, in: B. Van der Walle, M. Turoff, R. Hiltz (eds.), Information Systems for Emergency Management, AMIS, M.E. Sharpe, eISBN 978-0-7656-21351, 2009 [19] Bhatti R., Ghafoor A., Bertino E., Joshi J., X-GTRBAC: an XML-based policy specification framework and architecture for enterprise-wide access control, ACM Transactions on Information and System Security (TISSEC), v.8 n.2, p.187-227, May 2005 [20] Lampson B.W., Dynamic protection structures, AFIPS conference proceedings, FJCC 1969, p27-38. [21] Ferraiolo D. F., Cugini J., Kuhn D. R., Role Based Access Control: Features and Motivations, Computer Security Applications Conference, 1995 [22] Yuan E., Tong J.: Attribute Based Access Control (ABAC) for Web Services, IEEE International Conference on Web Services (ICWS 2005), Orlando Florida, July 2005 [23] CHARON, CHARON framework website, http://www.enviromatics.net/charon, 2009 [24] Denzer R, Güttler R., ORCHESTRA - An Information Infrastructure to Support Cross-Boundary Risk Management, MODSIM 2005, International Congress on Modelling and Simulation, Modelling and Simulation Society of Australia and New Zealand, December 2005, pp. 1951-1956 [25] Hafner M., Breu R., Security Engineering for ServiceOriented Architectures, Springer-Verlag GmbH, Heidelberg, XVI, 248 p., ISBN: 978-3-540-79538-4, 2009 [26] Usländer T. (ed.), Specification of the Sensor Service Architecture Version 2, Deliverable D2.3.3 of the European Integrated Project SANY, FP6-IST-033564, http://sanyip.eu/filemanager/active?fid=186, 2009

10