Threat Mitigation in WS- Environment

92 Copyright © 2010 Open Geospatial Consortium, Inc. Security measure Realization Authorization WS-Security provides the means to attach various tokens in the message. WS-Trust defines secure token service for managing and distribution of security tokens which may include authorization attributes in distributed environment. For example, SAML 2.0 profile of XACML 2.0 [11] may provide security token with certain authorization obligations. One can also use X.509 attribute certificates and certificate authorities. In addition, WS-Federation [9] provides authorization claims between federated partners. Non-repudiation XML signatures and WS-ReliableMessaging [2] may provide non- repudiation service. WS-ReliableMessaging defines ordered delivery, duplicate elimination, and guaranteed receipt while XML signatures ensures integrity of those artifacts – also see section 8.2 Data confidentiality Messages can be encrypted as specified by WS-Security. WS- Security allows encryption of any combination of body blocks, header blocks, and any of sub-structures by either a common symmetric key shared by the producer and the recipient or a symmetric key carried in the message in an encrypted form. For example, XML encryption can be used to encrypt XML contents. Data integrity Include message signatures in messages as specified by WS- Security. For example, XML signatures can be used. Availability WS-Trust and WS-Federation provides a mean of brokering identity management. This would ensure that only authenticated and authorized users can access certain information and perform operations. Privacy WS-Federation provides protection of the privacy claims across organizational boundaries. For example, WS-Federation defines a parameter to request a security token message that indicates which claims are requested to be protected. It provides a standard for confidential tokens, parameter confirmation, obtaining privacy statements Communication security WS-SecureConversation [8] defines security context establishment, sharing, and session key derivation. Example of using security transport protocol is SOAP over HTTPS.

8.1.6 Threat Mitigation in RESTful Environment

This section explains which technologies can be used in a RESTful environment to realize the security measures discussed in section 8.1.3. Copyright © 2010 Open Geospatial Consortium, Inc. 93 The suggested approach for the security implementation within a REST service is either 2-way SSL or HTTP Basic Authentication over 1-way SSL. This will provide point-to- point or transport level security. There are no specific standards for implementing security in a RESTful web service, although there are common practices. Table 38: Realization of security measures in a RESTful environment Security measure Realization Authentication In two-way SSL authentication mutual authentication, the SSL client application verifies the identity of the SSL server application, and then the SSL server application verifies the identity of the SSL- client application. Two-way SSL authentication is also referred to as client authentication because the application acting as an SSL client presents its certificate to the SSL server after the SSL server authenticates itself to the SSL client. Either self-signed certificates or certificates released by a trusted CA such as VeriSign can be used. In any case it is important to check the certificate for validity, including validation of revocation lists and the trusted root certificates. In the context of web browser clients, the use of the SAML 2 Web Browser SSO Profile can be used to create a security context that is typically maintained in secure cookies cookies that are only transmitted via HTTPS connections. Http Basic Authentication over one-way SSL enables the application operating as the SSL client to verify the identity of the application operating as the SSL server. The server can implement or use an existing identity management system API, such as SAML, OpenAuth or OAuth, to verify a users identity. This would require the users of the service to have an account with the third party - the Identity Provider. Authorization In an SSL implementation, either one-way or two-way, the digital certificate can contain information about a user including their role. The web service could authorize access to data based on the user’s role. Authorization could also be achieved via custom code implemented inside the service that would allow an administrator to configure access to individual users or a group of users. A developer could leverage existing third party identity management system APIs and data stores, such as an LDAP repository, to determine access controls on their service.