| Oracle® Fusion Middleware Security and Administrator's Guide for Web Services 11g Release 1 (11.1.1.5) Part Number B32511-05 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Middleware Security and Administrator's Guide for Web Services 11g Release 1 (11.1.1.5) Part Number B32511-05 |
|
|
PDF · Mobi · ePub |
Note:
This appendix summarizes the security standards for Oracle Infrastructure Web Services. For a complete list of the versions supported with links to the specifications, see "Supported Standards" in Oracle Fusion Middleware Concepts Guide for Oracle Infrastructure Web Services.For a description of standards for WebLogic Web services, see "Features and Standards Supported by WebLogic Web Services" in Introducing WebLogic Web Services for Oracle WebLogic Server
Security standards are implemented in non-XML frameworks at the transport level, and in XML frameworks at the application level.
The following sections describe the standards that are key to providing secure and manageable SOA environments at both the transport and application levels.
See Also:
For a complete list of standards supported by Oracle WebLogic Web services, see "Features and Standards Supported by WebLogic Web Services" in Introducing WebLogic Web Services for Oracle WebLogic Server.Oracle considers interoperability of Web services platforms to be more important than providing support for all possible edge cases of the Web services specifications. Oracle complies with the following specification from the Web Services Interoperability Organization and considers it to be the baseline for Web services interoperability:
Basic Security Profile 1.0: http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html
Secure Sockets Layer (SSL), also known as Transport Layer Security (TLS), is the most widely used transport-layer data-communication protocol. SSL provides the following:
Authentication—communication is established between two trusted parties.
Message confidentiality—data exchanged is encrypted.
Message integrity—data is checked for corruption.
Secure key exchange between client and server
SSL can be used in three modes:
No authentication: Neither the client nor the server authenticates itself to the other. No certificates are sent or exchanged. In this case, only confidentiality (encryption/decryption) is used.
One-way authentication (or server authentication): Only the server authenticates itself to the client. The server sends the client a certificate verifying that the server is authentic. This is typically the approach used for Internet transactions such as online banking.
Two-way authentication (or bilateral authentication): Both client and server authenticate themselves to each other by sending certificates to each other. This approach is necessary to prevent attacks from occurring between a proxy and a Web service endpoint.
SSL uses a combination of secret-key and public-key cryptography to secure communications. SSL traffic uses secret keys for encryption and decryption, and the exchange of public keys is used for mutual authentication of the parties involved in the communication.
The XML encryption specification describes a process for encrypting data and representing the result in XML. Specifically, XML encryption defines:
How digital content is encrypted and decrypted.
How the encryption key information is passed to a recipient.
How encrypted data is identified to facilitate encryption.
An XML document may be encrypted as a whole or in part.
Example A-1 illustrates credit card data represented in XML.
Example A-1 XML Representation of Credit Card Data
<PaymentInfo xmlns="http://www.example.com/payment">
<CreditCard>
<Name>John Smith</Name>
<CreditCardNumber>4019 2445 0277 5567</NCreditCardNumber>
<Limit>5000</Limit>
<Issuer>Example Bank</Issuer>
<Expiration>04/02</Expiration>
</CreditCard>
</PaymentInfo>
Example A-2 illustrates the same XML snippet with the credit card number encrypted and represented by a cipher value.
Example A-2 XML Representation of Encrypted Credit Card Data
<PaymentInfo xmlns='http://www.example.com/payment">
<CreditCard>
<Name>John Smith</Name>
<CreditcardNumber>
<EncryptedData xmlns="http://www..." Type="http://www...">
<CipherData>
<CipherValue>A23B4...5C56</CipherValue>
</CipherData>
</EncryptedData>
<Limit>5000</Limit>
<Issuer>Example Bank</Issuer>
<Expiration>04/02</Expiration>
</CreditCard>
</PaymentInfo>
See Also:
For more information about XML encryption, see "XML Encryption Syntax and Processing" specification at:
The XML Signature specification describes signature processing rules and syntax. XML Signature binds the sender's identity (or "signing entity") to an XML document. The document is signed using the sender's private key; the signature is verified using the sender's public key.
Signing and signature verification can be done using asymmetric or symmetric keys. XML Signature also ensures non-repudiation of the signing entity, that is, it provides proof that messages have not been altered since they were signed.
A signature can apply to a whole document or just part of a document, as shown in the following example.
Example A-3 XML Representation of Signed Data
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<!-- The signedInfo element allows us to sign any portion of a
document -->
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www..."/>
<SignatureMethod Algorithm="http://www..."/>
<Reference URI="#Body">
<DigestMethod Algorithm="http://www..."/>
<DigestValue>o+jtqlieRtF6DrUb...X8O9M/CmySg</DigestValue>
</Reference>
</SignedInfo>
<!-- Following is the result of running the algorithm over the
document. If changes are made to the document, the SignatureValue is
changed. The security application verifies the SignatureValue,
extracts the X.509 cert and uses it to authenticate the user -->
<SignatureValue>oa+ttbsvSFi...EtRD2oNC5</SignatureValue>
<KeyInfo>
<KeyValue>
<!-- Following is the public key that matches the private key
that signs the document -->
<RSAKeyValue>
<Modulus>5TT/oolzTiP++Ls6GLQUM8xoFFrAlZQ...</Modulus>
<Exponent>EQ==</Exponent>
</RSAKeyValue>
</KeyValue>
<!-- Following is the certificate -->
<X509Data>
<X509Certificate>wDCCAXqgAwIBAgI...</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
See Also:
For more information about XML Signature, see the "XML Signature Syntax and Processing" specification at:
Web Services Security (WS-Security) specifies SOAP security extensions that provide confidentiality using XML Encryption and data integrity using XML Signature. WS-Security also includes profiles that specify how to insert different types of binary and XML security tokens in WS-Security headers for authentication and authorization purposes. WS-Security token profiles are described in the following sections
See Also:
For more information about WS-Security and its specification, see:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
Web services security supports the following security tokens:
Username—defines how a Web service consumer can supply a username as a credential for authentication). For more information, see "Username"
X.509 certificate—a signed data structure designed to send a public key to a receiving party. For more information, see "X.509 Certificate"
Kerberos ticket—a binary authentication and session token. For more information, see "Kerberos Token"
Security Assertion Markup Language (SAML) assertion—shares security information over the Internet through XML documents. For more information, see "SAML Token"
The username token carries basic authentication information. The username-token element propagates username and password information to authenticate the message.
See Also:
For more information about the username token profile, see:
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf
An X.509 digital certificate is a signed data structure designed to send a public key to a receiving party. A certificate includes standard fields such as certificate ID, issuer's Distinguished Name (DN), validity period, owner's DN, owner's public key, and so on.
Certificates are issued by certificate authorities (CA). A CA verifies an entity's identity and grants a certificate, signing it with the CA's private key. The CA publishes its own certificate which includes its public key.
Each network entity has a list of the certificates of the CAs it trusts. Before communicating with another entity, a given entity uses this list to verify that the signature of the other entity's certificate is from a trusted CA.
See Also:
For more information about the X.509 certificate token profile, see:
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf
Kerberos token is a cross-platform authentication and single sign-on system. The Kerberos protocol provides mutual authentication between two entities relying on a shared secret (symmetric keys). Kerberos uses the following terminology:
A Principal is an identity for a user (i.e., a user is assigned a principal), or an identity for an application offering Kerberos services.
A Realm is a Kerberos server environment; a Kerberos realm can be a domain name such as EXAMPLE.COM (by convention expressed in uppercase).
See Also:
For more information about the Kerberos token profile 1.1, see:
http://www.oasis-open.org/committees/download.php/16788/wss-v1.1-spec-os-KerberosTokenProfile.pdf
Kerberos involves a client, a server, and a trusted party to mediate between them called the Key Distribution Center (KDC). Each Kerberos realm has at least one KDC. KDCs come in different packages based on the operating platform used (for example, on Microsoft Windows, the KDC is a domain service). The Kerberos Token profile of WS-Security allows business partners to use Kerberos tokens in service-oriented architectures.
The Security Assertion Markup Language (SAML) is an open framework for sharing security information over the Internet through XML documents. SAML was designed to address the following:
Limitations of web browser cookies to a single domain: SAML provides a standard way to transfer cookies across multiple Internet domains.
Proprietary web single sign-on (SSO): SAML provides a standard way to implement SSO within a single domain or across multiple domains. This functionality is provided by the Oracle Identity Federation product.
Federation: SAML facilitates identity management (e.g., account linking when a single user is known to multiple web sites under different identities), also supported by Oracle Identity Federation.
Web Services Security: SAML provides a standard security token (a SAML assertion) that can be used with standard web services security frameworks (e.g., WS-Security) – This is the use of SAML that is particularly relevant to web services security, fully supported by Oracle WSM.
Identity propagation: SAML provides a standard way to represent a security token that can be passed across the multiple steps of a business process or transaction, from browser to portal to networks of web services, also a feature supported by Oracle WSM.
The SAML framework includes 4 parts:
Assertions: How you define authentication and authorization information.
Protocols: How you ask (SAML Request) and get (SAML Response) the assertions you need.
Bindings: How SAML Protocols ride on industry-standard transport (e.g., HTTP) and messaging frameworks (e.g., SOAP).
Profiles: How SAML Protocols and Bindings combine to support specific use cases.
In the context of WS-Security, only SAML assertions are used. The protocols and bindings are provided by the WS-Security framework. SAML is widely adopted by the industry, both for browser-based federation and federation enabled by web services flows.
SAML assertions are very popular security tokens within WS-Security because they are very expressive and can help prevent man-in-the-middle and replay attacks.
Typically, a SAML assertion makes statements about a principal (a user or an application). All SAML assertions include the following common information:
Issuer ID and issuance timestamp
Assertion ID
Subject
Name
Optional subject confirmation (for example, a public key)
Optional conditions (under which an assertion is valid)
Optional advice (on how an assertion was made)
SAML assertions can include three types of statements:
Authentication statement: issued by an authentication authority upon successful authentication of a subject. It asserts that Subject S was authenticated by Means M at Time T.
Attribute statement: issued by an attribute authority, based on policies. It asserts that Subject S is associated with Attributes A, B, etc. with values a, b, and so on.
Authorization decision statement (deprecated in SAML 2.0, now supported by XACML): issued by an authorization authority which decides whether to grant the request by Subject S, for Action A (e.g., read, write, etc.), to Resource R (e.g., a file, an application, a Web service), given Evidence E.
SAML assertions can be embedded (i.e., a SAML assertion can contain another SAML assertion). SAML assertions can be signed (using XML Signature) and/or encrypted (using XML Encryption).
See Also:
For more information about the SAML token profile, see:
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf
Together with WS-Security, WS-Policy is another key industry standard for Oracle Fusion Middleware security.
A Web service provider may define conditions (or policies) under which a service is to be provided. The WS-Policy framework enables one to specify policy information that can be processed by web services applications, such as Oracle WSM.
A policy is expressed as one or more policy assertions representing a Web service's capabilities or requirements. For example, a policy assertion may stipulate that a request to a Web service be encrypted. Likewise, a policy assertion can define the maximum message size that a Web service can accept.
WS-Policy expressions are associated with various web services components using the WS-PolicyAttachment specification. WS-Policy information can be embedded in a WSDL file, thus making it easy to expose Web service policies through a UDDI registry.
WS-SecurityPolicy is part of the Web Services Secure Exchange (WS-SX) set of specifications hosted by OASIS (in addition to WS-SecurityPolicy, the WS-SX technical committee defines two other sets of specifications: WS-Trust and WS-SecureConversation, described later in this chapter).
WS-SecurityPolicy defines a set of security policy assertions used in the context of the WS-Policy framework. WS-SecurityPolicy assertions describe how messages are secured on a communication path. Oracle has contributed to the OASIS WS-SX technical committee several practical security scenarios (a subset of which is provided by Oracle WSM 11g). Each security scenario describes WS-SecurityPolicy policy expressions.
WS-SecurityPolicy scenarios describe examples of how to set up WS-SecurityPolicy policies for several security token types described in the WS-Security specification (supporting both WS-Security 1.0 and 1.1). The subset of the WS-SecurityPolicy scenarios supported by Oracle WSM 11g represents the most common customer use cases. Each scenario has been tested in multiple-vendor WS-Security environments.
To illustrate WS-SecurityPolicy, let's use a scenario supported by Oracle WSM: UsernameToken with plain text password. As mentioned earlier, Username token is one of the security tokens specified by WS-Security. This specific scenario uses a policy that says that a requester must send a password in a Username token to a recipient who has authority to validate that token. The password is a default requirement for the WS-Security Username Token Profile 1.1.
This scenario is only recommended when confidentiality of the password is not an issue, such as a pre-production test scenario with dummy passwords.
Example A-4 Example of WS-SecurityPolicy
<wsp:Policy>
<sp:SupportingTokens>
<wsp:Policy>
<sp:UsernameToken/>
</wsp:Policy>
</sp:SupportingTokens>
</wsp:Policy>
An example of a message that conforms to the above stated policy is shown below.
Example A-5 Example of Message Conforming to WS-SecurityPolicy
<?xml version="1.0" encoding="utf-8" ?>
<soap:Envelope xmlns:soap="...">
<soap:Header>
<wsse:Security soap:mustUnderstand="1" xmlns:wsse="...">
<wsse:UsernameToken>
<wsse:Username>Marc</wsse:Username>
<wsse:Password Type="http://docs.oasis open.org...>
XYZ
</wsse:Password>
<wsse:Nonce EncodingType="...#Base64Binary">qB...</wsse:Nonce>
<wsu:Created>2008-01-02T00:01:03Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
</soap:Header>
<soap:Body>
<Oracle xmlns=http://xmlsoap.org/Oracle>
<text>EchoString</text>
</Oracle>
</soap:Body>
</soap:Envelope>
The example above contains a <Nonce> element and a <Created> timestamp, which, while optional, are recommended to improve security of requests against replay and other attacks. A nonce is a randomly generated (unique) number. The timestamp can be used to define the amount of time the security token is valid.
SOAP does not provide a standard way to specify where a message is going or how responses or faults are returned. WS-Addressing provides an XML framework for identifying web services endpoints and for securing end-to-end endpoint identification in messages.
A Web service endpoint is a resource (such as an application or a processor) to which web services messages are sent.
The following is an example using WS-Addressing (wsa is the namespace for WSAddressing):
Example A-6 Example of WS-Addressing
<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<S:Header>
<wsa:MessageID>http://example.com/xyz-abcd-123</wsa:MessageID>
<wsa:ReplyTo>
<wsa:Address>http://example.myClient1</wsa:Address>
</wsa:ReplyTo>
WS-Addressing is transport-independent; that is, the request may be over JMS and the response over HTTP. WS-Addressing is used with other WS-* specifications, such as WS-Policy.
The WS-Trust 1.3 specification (http://docs.oasis-open.org/ws-sx/ws-trust/v1.3/ws-trust.html) defines extensions to WS-Security that provide a framework for requesting and issuing security tokens, and to broker trust relationships. WS-Trust extensions provide methods for issuing, renewing, and validating security tokens.
To secure communication between a Web service client and a Web service, the two parties must exchange security credentials. As defined in the WS-Trust specification, these credentials can be obtained from a trusted SecurityTokenService (STS), which acts as trust broker. That is, the STS must be trusted by both the Web service client and the Web service in order to provide interoperable security tokens.
WS-ReliableMessaging (WS-RM) defines a framework for identifying and managing the reliable delivery of messages between Web services endpoints. WS-RM is predicated on the SOAP messaging structure (SOAP binding) and relies on WS-Security, WS-Policy, and WS-Addressing to provide reliable messaging.
WS-RM defines a reliable messaging (RM) source (the party that sends the message) and an RM destination (the party that receives the message). WS-RM mandates prerequisites, for example, trust between endpoints must be established, and the message and endpoints must be formally identified (this is achieved through the use of the complementary WS-* specifications mentioned earlier).
WS-RM Policy defines a policy assertion that leverages the WS-Policy framework in order to enable an RM destination and an RM source to describe their requirements for a given sequence.
|
 Copyright © 2007, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|