12
Cop
8.3.3 Indirect Brokered Trust
Indirect brokered trust is an extension of direct brokered trust, where is no single CA which has a trust relationship to both communication partners. Thus, trust has to be
brokered between several CAs, resulting in a trust chain between the communication partners.
yright © 2009 Open Geospatial Consortium, Inc.
9 Abstract Security Architecture
A security architecture is never self-contained, rather it being an overlay to a domain architecture. OGC defines service architecture, is based on the OWS Common standard
[1] and extended by other implementation standards.
This section discusses the security approach actually taken within the OWS-6 testbed.
9.1 Security Extensions to Existing OGC Architecture
In the OGC, a security architecture should leverage the existing OGC Standards by defining generic security extensions being applicable to all OGC standards based on
OWS Common [1]. On an abstract level, such extensions should be independent of specific technology bindings, leading to a common abstract security architecture for OGC
web services.
For the testbed approach to access control using the OGC service model, the following extensions are needed:
• Security metadata
Services should be able to expose their security requirements to requesting clients as part of the technical service metadata. This may include
Direct Trust Direct Trust
CA 1
Indirect Brokered Trust CA 2
CA n
Direct Trust
Direct Trust
Cop
o requiring certain security tokens such as identity tokens or license tokens
o requiring the use of transport level security
o requiring the use of message level encryption
o requiring requests to be digitally signed
• Protocol extensions
To submit security-related information such as security tokens, extensions to the OGC service protocols should be defined, allowing such information to be
submitted together with request andor response messages.
• Additional error definitions
If a client fails to fulfill a service’s security requirements or if access is denied to a certain request, the service may respond with an appropriate error message,
indicating the reason for the failure of the request. Although error messages need to be specified, their use should be optional, since error messages may lead to
undesired information leakage e.g. a message indicating that access to a certain resource is denied nevertheless indicates that this resource actually exists.
9.2 Static View: Security Interactions
The security components used to provide access control in OWS-6 are shown in Figure 1. This architecture relies on the access control architecture defined by OASIS in the
‘eXtensible Access Control Markup Language’ XACML standard [10].
cmp Abstract_Security_Components
Client PEP
OWS Authentication
Serv ice PDP
Metadata Secured OWS
Authenticate Authorize
OWS
Figure 1, Abstract Security Components
The OWS to be secured is protected by a Policy Enforcement Point PEP, which is responsible for receiving requests, analyzing them and delegate access decisions to the
Policy Decision Point PDP.
The PDP receives an authorization request and matches it against the available policies. The decision is enforced by the PEP. In case of a ‘Permit’ decision the request is
yright © 2009 Open Geospatial Consortium, Inc.
13
14
Copyright © 2009 Open Geospatial Consortium, Inc.
forwarded to the OWS. A ‘Permit’ decision can include obligations which have to be fulfilled by the PEP. Whenever the PEP is unable to fulfill an obligation it has to deny
access to the OWS, as it is required by a ‘Deny’ decision from the PDP.
A PDP may also respond with ‘Indeterminate’ or ‘NotApplicable’, both of them also resulting in a denial of access due to the denial biased characteristics of the PEPs used in
this testbed. .
9.3 Dynamic View: Security Workflows
Kategori