| Oracle® Application Server Web Services Security Guide 10g (10.1.3.5.0) Part Number E13983-01 |
|
|
View PDF |
| Oracle® Application Server Web Services Security Guide 10g (10.1.3.5.0) Part Number E13983-01 |
|
|
View PDF |
This chapter introduces essential Web service security concepts, standards, and specifications. It is divided into the following sections:
Historically, the majority of Web services have been based on the same enabling technology that underlies the Web, namely HTTP. As a result, common technologies that secure Web applications, such as basic authentication and SSL, work equally well with Web services. These security technologies have been effective for years for all sorts of online business transactions, and they work equally well for Web services.
SSL, however, does have limitations. SSL for Web services is an all-or-nothing proposition: it often secures the entire wire protocol rather than just the SOAP message sent over the protocol. It doesn't let developers apply different levels of security to different parts of a document. Because of its point-to-point structure, SSL doesn't support chained services or workflow applications where user credentials can be passed through each stop in a transaction chain. This leaves the messages unsecured at each intermediary checkpoint. SSL also does not support the concept of an audit trail.
The answer to providing both message- and transport-level security lies with the OASIS standard, WS-Security, released as a full industry-recognized recommendation in April 2004. WS-Security defines a mechanism for adding transport independence and different levels of security to SOAP messages.
WS-Security offers multiple ways to authenticate. In WS-Security, it is easy to associate different identities with service requests. These identities can be used to enforce authorization after authentication.
WS-Security offers support for SOAP traffic involving intermediaries.
WS-Security is transport-independent, which gives greater transport flexibility.
WS-Security is targeted security. For example, you can sign or encrypt the whole message body, or just a single XML element of the body payload.
If there is a need to apply integrity and confidentiality at a fine-grained level instead of applying to the entire SOAP message, XML signature and encryption can be used to protect the SOAP body, header block, or portions of either. If the SOAP message needs to be protected beyond the transport session, message-level security can be used. If there is a need to use different forms of authentication, then message-level security authentication tokens can be used, such as username token, X.509 token, or SAML token.
The concepts fundamental to security are authentication, message integrity, and message confidentiality.
Authentication — "Who is trying to access my services?" Applications need to know whom they're serving.
Message integrity —"Was the message lost, destroyed, or modified in transit, either accidentally or deliberately?" Applications must validate messages.
Message confidentiality—"Can anybody else read this message?" Applications may need to encrypt data between endpoints, revealing data to only applications that need to see it.
A number of Web services and security-related terms and concepts are used throughout this book. They are described in the following sections.
The SOAP protocol is an XML-based standard for Web service request and response messages, which are normally transmitted over the HTTP or HTTPS (HTTP with SSL) protocols. WS-Security is an XML-based extension to the SOAP description, designed to fit within the SOAP message context. To see this, one must first understand the anatomy of a SOAP message.
In the XML schema definition for SOAP, the <Envelope> element is the root element of a SOAP message. A SOAP message can also have headers, a body, or a fault element. Example 1-1 illustrates the contents the SOAP <Envelope> element.
Example 1-1 Contents of the SOAP <Envelope> Element
<env:Envelope>
<env:Header>
</env:Header>
<env:Body>
.
.
.
</env:Body>
<env:Envelope>
Note:
This example illustrates a SOAP request envelope. There is also a response envelope, which can contain a SOAP fault element.Although Web services developers are primarily concerned with the contents of the SOAP body, most security-related elements appear in the SOAP header. The body itself can be encrypted, in which case it contains ciphertext.
A Web service security policy determines the security mechanism that is applied to a SOAP message. Security policies can be applied to the Web service on the server side and to the Web service client. Oracle Application Server Web Services Security recognizes the following types and levels of security policies.
An inbound policy determines the security mechanisms applied to the inbound SOAP message. The decrypt value and the verify-username-token value are two examples of inbound policies. The decrypt value represents a policy which is used for decrypting the inbound SOAP message. The verify-username-token value represents a policy; this indicates that the incoming SOAP request is carrying a username token which must be verified and authenticated.
To configure an inbound policy, you can use Application Server Control, Oracle JDeveloper, or create the configuration manually. The security configuration appears as subelements beneath an <inbound> element. The <inbound> element and its configuration can appear in the oracle-webservcies.xml file for a Web service application and <generated_name>_Stub.xml file for a Web service client.
See Also:
"Security Elements for Inbound Messages" for more information about the contents of the <inbound> element.
An outbound policy determines the security mechanisms applied to the outbound SOAP message. The <encrypt> value and the <username-token> value are two examples of outbound policies. The <encrypt> value represents a policy, which is used for encrypting the outbound SOAP message. The <username-token> value represents a policy, which indicates that a username token must be included in the outgoing SOAP message.
To configure an outbound policy, you can use Application Server Control, Oracle JDeveloper, or create the configuration manually. The security configuration appears as subelements beneath an <outbound> element. The <outbound> element and its configuration can be used in the oracle-webservcies.xml file for a Web service application and <generated_name>_Stub.xml file for a Web service client.
See Also:
"Security Elements for Outbound Messages" for more information about the contents of the <outbound> element.
A global-level security policy is a security policy that is applied to all of the Web services deployed in an OC4J instance. Global-level policies can be configured only on the server side.
You can configure the following items at the global level:
Keystore, signature and encryption keys
Nonce configuration
Inbound policy
Outbound policy
In the Web service context, a port is analogous to an application. A port-level security policy is a security policy that is applied to all operations defined in that Web service. Port-level policies can be configured on the server and the client side.
You can configure the following items at the port level:
Keystore, signature and encryption keys
Nonce configuration
Inbound policy
Outbound policy
An operation-level security policy is a security policy that is applied to a particular operation of a Web service. Operation-level policies can be configured on the server and the client side.
You can configure the following items at the operation level:
Inbound policy
Outbound policy
A request envelope contains the information required to process a remote call. Each request message contains a message header and a message body. The header stores processing information such as message routing, requirements information, and security information. The body of the message stores the information required to process the call; this information is also known as the payload.
The payload contains the following items:
Name of the service called
Location of the service
Parameter name and data passed to the service
SOAP response envelope format-type is identical to the request. The only difference is that the IN parameter is replaced by an OUT parameter. The application's output is included in the SOAP body.
Note:
The structure of the request and response envelopes might differ based on whether the service supports the RPC-encoded and/or document-literal message format. For more information on supported message formats, see "Oracle Application Server Web Services Messages" in the Oracle Application Server Web Services Developer's Guide.The XML signature specification describes digital signature processing rules and syntax. XML signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere.
An XML signature contains the basic hash of the signed document, along with information that tells the recipient of the document what data was signed and which algorithms were used. An XML signature can be included inside the document to which the signature applies, or it can exist in a separate document. An XML signature can be applied to document subsets, or even to non-XML data.
XML Signature supports various types of signature, including:
enveloped—the XML signature is embedded within the signed document.
enveloping—the signed data is embedded within the XML signature.
detached—the signature corresponds to data external to the signature element.
See Also:
The "XML Signature Syntax and Processing" specification for more information about XML Signature.
XML Signatures and Web Services
For a Web service, XML digital signatures ensure the validity and identity of SOAP messages sent between Web service clients and services. They are similar in concept to a handwritten signature, where only one person, the signer, can produce the signature. Signature validation is performed in two steps.
Compute the message digests of all SOAP message elements to be signed, then place the digests in the <SignedInfo> element of the message signature.
Compute the message digest of the <SignedInfo> element, then sign this digest with the signer's private key. Place the key used for signing in the <KeyInfo> element.
The signed SOAP message then is transmitted and verified at the Web service endpoint by the signer's public key. The following steps illustrate how verification works.
Recalculate the value of the <SignedInfo> element using the digest algorithm specified in the <SignatureMethod> element. Use the public key to verify that the value of the <SignatureValue> element is correct for the digest of the <SignedInfo> element.
Recalculate the digests of the references contained within the <SignedInfo> element and compare them to the digest values expressed in each <Reference> element's corresponding <DigestValue> element.
Example 1-2 illustrates the XML representation of signed data. The body of the SOAP message is signed with the RSA-SHA1 algorithm.
Example 1-2 XML Representation of Signed Data
<dsig:Signature xmlns="http://www.w3.org/2000/09/xmldsig#"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:SignedInfo>
<dsig:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<dsig:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#*rsa-sha1*"/>
<dsig:Reference URI="*#body*">
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<dsig:DigestValue>p5vhdagV0tjJafczbLB/I4aonlg=</dsig:DigestValue>
</dsig:Reference>
</dsig:SignedInfo>
<dsig:SignatureValue>QKEJpRGwwRApPFWfA1R/6K4JFwCxyH2Ur0mdzTnzmpf
8DNvDVB9xdF9PVsQ68vEey8afbrL/Qwujghoq3gF22VlEBPj
TDrRTZ9JgnRVbOt/M/SacHP/BZn9gSfLySpJaQIj7x
MUbm5s29JiUvjQ0oR0/Skn+8f+KeQD0QEmbWX8=
</dsig:SignatureValue>
<dsig:KeyInfo>
<wsse:SecurityTokenReference xmlns="http://docs.oasis-open.org/wss/2004/01/
oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/
01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
wsu:Id="_str"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/
01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:Reference xmlns="http://docs.oasis-open.org/wss/2004/
01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/
01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
URI="#_bst"/>
</wsse:SecurityTokenReference>
</dsig:KeyInfo>
</dsig:Signature>
The XML encryption specification describes a process for encrypting data and representing the result in XML. The data can be arbitrary; for example, it can be an XML document, an XML element, or XML element content. The result of encrypting data is an XML encryption element which contains (by using one of its children's content) or identifies (by using a URI reference) the cipher data. The standard allows selected parts of a document to be encrypted, while the document as a whole remains valid XML.
XML encryption supports different encryption types such as:
symmetric key encryption
public key encryption
See Also:
"XML Encryption Syntax and Processing" specification for more information about XML Encryption.
XML Encryption and Web Services
For a Web service, XML encryption provides security for applications that require a secure exchange of data. While SSL was considered the standard way to secure data exchanges, it has limitations. For example, assume that a document visits several web services before hitting its eventual endpoint. By using XML encryption, the document can be encrypted while at rest, or in transport. It is also possible to encrypt only portions of a document, instead of the whole document.
Example 1-3 illustrates credit card data represented in XML.
Example 1-3 XML Representation of Credit Card Data
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith</Name>
<CreditCard Limit='5,000' Currency='USD'>
<Number>4019 2445 0277 5567</Number>
<Issuer>Example Bank</Issuer>
<Expiration>04/02</Expiration>
</CreditCard>
</PaymentInfo>
Example 1-4 illustrates the same XML snippet with the credit card number, spending limit, issuing bank, and expiration date encrypted and represented by a cipher value.
Example 1-4 XML Representation of Encrypted Credit Card Data
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith</Name>
<EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element'
xmlns='http://www.w3.org/2001/04/xmlenc#'>
<CipherData>
<CipherValue>A23B45C56</CipherValue>
</CipherData>
</EncryptedData>
</PaymentInfo>
The Security Assertion Markup Language (SAML) is an XML-based framework for exchanging security information. This security information is expressed in the form of assertions about subjects, either human or computer, that have identities in some security domain. One example of a subject is a person, who is identified by his or her email address in a particular Internet DNS domain. Assertions convey information about authentication acts performed by subjects, attributes of subjects, as well as authorization decisions about whether subjects are allowed to access certain resources.
SAML provides a flexible and extensible framework for business and Web services to exchange security information, such as authentication, authorization, and attributes, about their users. For example, SAML allows one service to vouch for a user's authentication to another service. This allows useful activities, such as single sign-on to multiple services.
SAML allows one service to inform another service whether a user is allowed to access a given resource. This allows policy enforcement to be decoupled from resource services.
SAML allows attribute information about a user, such as work-site address, to be communicated between services as the user moves from one site to another.
Oracle's Web Services Security model supports end-to-end security by using message-level security. This means that in addition to the connection, the SOAP message itself is secure even when it is transferred across multiple intermediaries. The SOAP message is digitally signed and encrypted. You can apply signature and encryption at a granular level by specifying which elements you want to sign and encrypt. The client and the application can authenticate each other by passing various authentication tokens such as username token, X.509 token, or SAML token.
Existing technologies such as SSL/TLS can be used to secure the transport channel. SSL allows two applications to securely connect over a network and authenticate each other. It also enables you to encrypt the data exchanged between the applications. In Oracle's Web Services Security model, this transport security mechanism can be used to provide point-to-point security, data integrity, and data confidentiality.
The Web Services Security (WS-Security) specification describes enhancements to SOAP 1.1 that increase the protection and confidentiality of messages. These enhancements include functionality to secure Simple Object Access Protocol (SOAP) messages through XML digital signature, confidentiality through XML encryption, and credential propagation through security tokens. The goal of the enhancements is to provide greater overall protection for communications over Web services.
WS-Security provides this protection by defining mechanisms for associating tokens with messages. It is completely extensible in that it can support multiple token formats.
The specification includes descriptions of how to include the following security tokens and keys:
binary security tokens using X.509 and Kerberos ticket
text-based tokens, such as the username token
signature and encryption keys
There are no restrictions on the types of credentials that you can include with a message.
Oracle Web Services Security provides support for WS-Security, including XML signature and encryption, and credential propagation through username, X.509, and SAML token profiles.
See Also:
See the following Web site for more information on WS-Security and its specification.
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
OracleAS Web Services Security supports the use of the following security tokens.
The usename token carries basic authentication information. The username-token element propagates user name and password information to authenticate the message. The information provided in the token and the trust relationship provide the basis for establishing the identity of the user.
See Also:
See the following Web site for more information on the username token profile.
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf
X.509 certificate with the user's credentials can be passed in the SOAP message.It can be used to sign the SOAP message for encryption and decryption only. For signature, the X.509 token can be used only for signature verification.
See Also:
See the following Web site for more information on the X.509 token profile.
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf
SAML security tokens are composed of assertions: one or more statements about a user, such as an authentication or attribute statement. SAML tokens are attached to SOAP messages by placing assertion elements inside the header.
See Also:
See the following Web site for more information on the SAML token profile.
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf
A keystore is used to store certificates, including the certificates of all trusted parties, for use by a program. Through its keystore, an entity, such as OC4J (for example) can authenticate other parties, as well as authenticate itself to other parties. Oracle HTTP Server has what is called a wallet for the same purpose.
OracleAS Web Services Security implementation supports the Java Key Store (JKS) and the Oracle Wallet and PKCS#12 keystore types. You can use Oracle Wallet or JKS as your keystore for storing private keys, public keys, and trusted CA certificates.
Oracle Wallet contains a user private key, a user certificate and a set of trust points (that is, the list of root certificates the user trusts). It implements the storage and retrieval of credentials for use with various cryptographic services. Oracle Wallet files are actually PKCS#12 files, which can be parsed, created, and otherwise, manipulated with the orapki tool, Oracle Wallet Manager, and Open SSL.
This section contains the following topics.
OracleAS Web Services Security is defined by the following specifications and standards.
Web Services Security (WS-Security) defines an open security standard.
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
XML Digital Signature defines how to verify the integrity of an XML object.
SAML tokens assert that the SAML user or subject has already been authenticated.
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf
X.509 tokens can be used to authenticate the user based on the trust relationship.
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf
Username tokens propagate user name and password information.
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf
Web Service Interoperability (WS-I) is a Web service organization that creates, promotes, and supports generic protocols for the interoperable exchange of messages between Web services.
The following Web Services Interoperability Organization (WS-I) document presents a full discussion of security challenges and threats in today's Web services environment.
http://www.ws-i.org/Profiles/BasicSecurity/SecurityChallenges-1.0.pdf.
In OracleAS Web Services, all WS-Security features, including digital signatures, encryption, and authentication, are implemented using a prebuilt JAX-RPC handler called an interceptor. Whenever a Web service client requests that a message be sent, the SOAP message is "intercepted" by the JAX-RPC handler. The interceptor adds the authentication, signature, and encryption WS-Security elements to the SOAP message, then forwards the message to the receiving Web service.
Each receiving Web service also has interceptors that can decrypt, verify signatures, and authenticate the incoming message.
Figure 1-1 illustrates the actions of the framework. The numbers in the illustration correspond to the following steps.
A Web service client sends a message to a Web service. The client interceptor adds the authentication, signature, and encryption WS-Security elements to the outbound SOAP message, then forwards the modified message to the receiving Web service.
The service interceptor intercepts the message and decrypts, verifies, and authenticates the message.
When sending a response message, the service interceptor in the Web service adds a WS-Security header with integrity and confidentiality.
The client interceptor interprets the header and delivers it to the client application.
See Also:
Chapter 5, "Secure Web Service Usage Scenarios" for more information on common use cases.
The service security interceptor acts as a filter on incoming SOAP messages. The security settings in the deployment descriptor describes the configuration that drives the interceptor. The service interceptor is responsible for decrypting, verifying, and authenticating (in that order) the incoming request message. When sending a response message, the service interceptor embeds a WS-Security header and provides for integrity and confidentiality of the outbound response message. The main intent of the service interceptor is to establish a security context of execution for SOAP operations.
Client handlers act as peers for the service handlers on the Web service client side. The client interceptor follows a set order of processing when it adds authentication tokens to, signs, and encrypts a SOAP message.
Figure 1-2 illustrates the movement of data through the client and service handlers. The client handler first collects authentication information and inserts it as a WS-Security token. This is followed by signature computation and encryption of the message. Configuration that resides in a Stub deployment descriptor determines what parts of the message must be integrity/confidentiality protected.
Figure 1-2 Data Flow Through Security Handlers
When the Oracle WS-Security runtime is involved in both the client and server, security interceptors are available at both sides, and these intercepts load security policies specified in configuration files. Many other types of clients (for example, .NET clients) understand and generate WS-Security headers within SOAP envelopes. A receiving interceptor enforces security policies; a sending interceptor intercepts a message and modifies it based on security requirements of the target receiver. For example, if the target receiver requires a message to be signed, the sender signs the message.
The Oracle WS-Security component is fully integrated with the OracleAS Web Services security infrastructure, which is based on the J2EE security model. For instance, when a request message contains a user name and password, the security handler authenticates by leveraging the underlying OracleAS JAAS Provider infrastructure. If authentication succeeds, a user identity (JAAS Subject) is established in the execution context, and further resource access is authorized by the container based on this identity. It should be noted that the security interceptor helps establish the identity against which the operation can be authorized. Server-side handlers leverage the OracleAS JAAS Provider for the formulation of Subjects and associate the correct Principal instances (users and/or roles) with each Subject during the commit phase of JAAS authentication. After that point, the asserted or authenticated Principal instances contained in Subject are used as a basis for J2EE and JAAS authorization.
The OracleAS Web Services architecture is built to support secure communications using a declarative model that requires a minimum of developer effort. An interceptor framework automates common security tasks, such as encrypting portions of the message body.
Figure 1-3 illustrates the overall architecture of WS-Security architecture for the Oracle Web service stack.
Figure 1-3 Web Services Security Architecture
The major components of the Oracle WS-Security architecture are the client and service security interceptors. These interceptors plug into the OracleAS Web Services management framework and work in tandem with other interceptors, including those that implement auditing, logging, and reliability.
The following sections describe how the Web service security interceptor integrates with the OracleAS Web Services Security framework.
OracleAS Web Services provides an implementation of Oracle Application Server Java Authentication and Authorization Service (JAAS) Provider for J2EE applications that is fully integrated with J2EE declarative security. This allows J2EE applications to take advantage of the JAAS constructs such as principal-based security and pluggable login modules. OracleAS Web Services Security provides out-of-the-box JAAS authentication login modules that allow J2EE applications running on OracleAS Web Services to leverage the central security services of Oracle Identity Management.
The JAAS Provider ensures secure access to and execution of Java applications, and integration of Java-based applications with Oracle Application Server Single Sign-On.
The OC4J 10.1.3.1 implementation packages a lighter-weight Java single sign-on (Java SSO) solution that does not rely on additional required infrastructure as is the case with other single sign-on options. This Java SSO, based on the OracleAS JAAS Provider identity management framework, can be used across Web applications in any of the following deployment scenarios:
Web applications are deployed in the same application EAR file.
Web applications are deployed in different application EAR files in the same OC4J instance.
Web applications are deployed in application EAR files in different OC4J instances, where the Web applications share a common security domain and cookie domain.
A single application, including Web applications, is deployed into multiple OC4J instances within an OC4J cluster.
See Also:
Oracle Containers for J2EE Security Guide for more information on Java SSO.
Oracle Identity Management provides an enterprise infrastructure for securing distributed enterprise applications. Oracle Identity Management is an integrated package of the Oracle Internet Directory (OID), an LDAP server, Single Sign-On, Security and User Management functionality.
Security in OracleAS Web Services is integrated with Oracle Identity Management. With this integration it is possible to perform the following services:
Secure Web services and authenticate against OID servers.
Propagate the Oracle Single Sign-On server authenticated user identity to remote Web services using standards based SAML token.
Implement fine-grained JAAS authorization for Web services. In this case, JAAS authorization policies are stored in the OID server.
See Also:
Oracle Identity Management Infrastructure Administrator's Guide for more information on the components that comprise Oracle Internet Directory.
Oracle Identity Management integration supports these Web services authentication mechanisms: HTTP basic, digest, username token, X.509 token, and SAML token.
The current release of Oracle Application Server Web Services Security is integrated with these releases of Oracle Identity Management: 10.1.2.0.1, 10.1.2.0.2, and 10.1.4.
See Also:
Oracle Containers for J2EE Security Guide for more information on integrating Oracle Identity Management with OC4J Security.
Web services security in OracleAS Web Services is integrated with external (non-Oracle) LDAP servers such as Active Directory. With this integration it is possible to:
Secure Web services and authenticate against LDAP servers.
Implement fine-grained JAAS authorization for Web services. In this case, JAAS authorization policies are stored in the XML file system-jazn-data.xml.
External LDAP server integration supports these Web services authentication mechanisms: HTTP basic, username token, X.509 token, and SAML token.
The current release of Oracle Application Server Web Services Security can be integrated with these external LDAP servers:
10g (10.1.3.1.0) Oracle Application Server Web Services Security is integrated with Windows 2000 and 2003 Active Directory.
10g (10.1.3.1.0) Oracle Application Server Web Services Security is integrated with Sun Java System Application Server (formerly known as iPlanet).
See Also:
Oracle Containers for J2EE Security Guide for more information on integrating Oracle Identity Management with OC4J security.
Oracle Access Manager is a complete solution for user identity and profile management, single sign-on, and access control. By integrating Oracle Access Manager with OC4J, a single Oracle Access Manager instance enables you to centralize authentication and authorization for one or more instances of OC4J. This single instance enables you to access single sign-on, centralize auditing, and provide stronger authentication options.
The Oracle Access Manager security provider for OC4J can be used to configure authentication and authorization for Web-based applications and single sign-on. It can also be used to configure EJB authentication and Web Service authentication schemes such as username token, X.509 and SAML.
See Also:
Oracle Containers for J2EE Security Guide for more information on Oracle Access Manager.
This section provides an overview of the parts of the Web service security configuration that can be set by the Oracle JDeveloper and Application Server Control tools.
This section contains these sub-sections:
See Also:
The on-line help for Application Server Control and Oracle JDeveloper. The on-line help provides detailed information of the individual security options that can be controlled by these tools.
Application Server Control can read and modify the security configuration of a deployed Web service. Once the configuration values have been modified and applied, the Web service can be restarted and run with the new values. Application Server Control can be used to set Web service security options on the port and operation level.
At the global level, you can use Application Server Control to set the keystore configuration and the signature and encryption keys. Like the security configuration, if you change the keystore, signature, or encryption values, you must restart the application for the new values to take effect.
See Also:
The Application Server Control on-line help for more information on how to use this tool to read and modify the configuration of a deployed Web service.
You can choose to employ a global keystore or an application-specific keystore for the Web service port. If you choose a global keystore, it applies to all applications deployed in that OC4J instance. If you choose an port-specific keystore, it must be deployed with your application. For a global keystore, you choose a keystore name, path, and password. You also choose identity certificates for message signature and encryption.
If you choose an application-specific keystore, you must also specify the identity certificates for signature and encryption to be used by all operations exposed by this Web service port.
Note:
Both server and trusted certificates are stored in the same keystore. This is different from how Secure Sockets Layer (SSL) or Oracle Remote Method Invocation (ORMI) is used in OC4J. You can use either Oracle Wallet or Java Keystore (JKS) as a keystore. "Using Keystores" provides more information on how to use these keystores.See Also:
"Keystore Elements" for more information on the elements and attributes that allow you to specify a global keystore.
"Signature and Encryption Key Elements" for more information on the elements and attributes that allow you to specify a port signature and encryption keys.
A security configuration for inbound and outbound SOAP messages can be set on the port-level and operation level. The same security operations (except keystore settings) are available at operation level.
A port-level setting applies to a Web service application. A port-level security configuration is used by all of the operations exposed by the Web service port. An operation-level setting is for a particular operation of the Web service application. A configuration setting made on the operation level overrides the setting made on the port level.
At the port-level you also choose keystore and identity certificates that will apply to all of the operations on the Web service. These values cannot be overridden on the operation level.
The port and operation level share the same security options for inbound SOAP messages. This section summarizes the options that Application Server Control can set.
Authentication for inbound messages—lets you specify whether the Web service should expect the message to authenticate by using a username/password (with or without a nonce or timestamp), a X.509 certificate, or a SAML token. "Security Elements for Inbound Messages" provides more information on the authentication elements that Application Server Control can set.
Signature verification for inbound messages—lets you specify whether to require the message body to be signed, whether a timestamp is present and a set of acceptable signature algorithms. "Signature Verification Elements for Inbound Messages" provides more information on the verification elements that Application Server Control can set.
Decryption for inbound messages—lets you specify whether the message body should be encrypted and a set of acceptable encryption algorithms. "Decryption Elements for Inbound Messages" provides more information on the decryption elements that Application Server Control can set.
The port and operation level share the same security options for outbound messages. This section summarizes the options that Application Server Control can set.
Signing for outbound messages—lets you specify whether to sign the message, add a timestamp, and an acceptable signature algorithm. "Signature Elements for Outbound Messages" provides more information on the signing elements that Application Server Control can set.
Encryption for outbound messages—lets you encrypt the body element of the outbound SOAP message by using either a request certificate or a public key by specifying an alias. "Encryption Elements for Outbound Messages" provides more information on the verification elements that Application Server Control can set.
Web Services Agent enables you to configure your Web service so that it can be managed by Oracle Web Services Manager (WSM). Oracle WSM and Oracle Web Services Manager Agent provide another technique of applying security policies to a Web service. Oracle Web Services Manager enables you to create policies declaratively, then export them to a file. The policies are applied to the Web service when you configure the Web Services Agent in Application Server Control. Agents are more capable than Web Services Security, in that they support different security algorithms and can provide integration with Oracle Access Manager and SiteMinder.
See Also:
"Oracle Web Services Manager" later in this chapter for more information on this tool.
Oracle JDeveloper can be used to develop OracleAS Web Services and client Web service management configuration files. Oracle JDeveloper can aid you in the initial creation of these files or it can be used to add management configuration to existing files.
Wizards in Oracle JDeveloper help you configure port and operation level security for inbound and outbound SOAP messages. They cannot be used to set security on the global level.
The port and operation level share the same security options for inbound and outbound messages. This section summarizes the options that Oracle JDeveloper wizards can set.
Web service authentication—lets you specify whether the Web service should expect to be accessed by using a username and password, a X.509 certificate, or a SAML token.
signature validation for inbound messages—lets you specify that inbound messages must be signed, and the signature algorithm.
decryption for inbound messages—lets you specify that inbound messages will be decrypted and the decryption algorithm.
signing outbound messages—lets you specify whether to add signatures and timestamps to outbound messages and a signing algorithm.
encryption for outbound messages—lets you specify whether to use a public key or the client-supplied certificate from a previously sent signed message, and the encryption algorithm.
keystore path—lets you specify credential store locations of the various keys required to implement the chosen security policies. Can be set on the port level only.
signature key—lets you specify the alias and password to access the required key for signing messages. Can be set on the port level only.
encryption key—lets you specify the alias and password to access the required key for decrypting messages. Can be set on the port level only.
See Also:
The Oracle JDeveloper on-line help for more information on security options in JDeveloper wizards.
Oracle Web Services Manager (WSM) is a Web services security and management solution that provides the visibility and control required to deploy Web services into production. With Oracle WSM, organizations can enjoy a common security infrastructure for all Web Service applications. This allows "best practice" security policies and monitoring to be deployed across existing or new services.
With Oracle WSM, an administrator creates security and management policies using a browser-based tool. A typical Web Service security policy could include the following items:
Decrypt the incoming XML message
Extract the user's credentials
Perform an authentication for this user
Perform an authorization check for this user and this Web Service
Write a log record containing the authorization checking information
If all of the steps are successful, pass the message to the intended Web Service
If all of the steps are not successful, return an error and write an exception record
To apply the security policy, Oracle WSM intercepts every incoming request to a Web service and applies any of the policy items in the list. As the policy is executed, Oracle WSM collects statistics about its operations and sends them to a monitoring server. The monitor displays errors, service availability data, and so on. As a result, each Web service in an enterprise network can automatically gain security and management control, without the service developer coding extra logic.
See Also:
Oracle Web Services Manager Installation Guide for information on integrating Oracle WSM with OC4J.
Oracle Web Services Manager User and Administrator Guide for information on using Oracle Web Services Manager.
The following sections describe the motivations for using Oracle WSM.
Web Services Access Control and Single Sign-On
Oracle WSM supports single sign-on, including authentication, authorization, and auditing for Web services. For example, a browser-based single sign-on cookie could be used for authentication and authorization in a Web service. Oracle WSM has tight integration with products such as Siteminder and Oracle Access Manager to support enterprise single sign-on solutions. It also supports authentication and authorization through Microsoft Active Directory, and LDAP.
Centralized Security Policy Management with Localized Enforcement
Oracle WSM allows organizations to minimize the duplication of effort required to build security into each service by leveraging a centralized security infrastructure. The OracleAS Web Services management solution provides the ability to add "best practice" security to an existing Web service, without requiring you to re-work the Service's code.
Place Security Policies in the hands of Security Professionals instead of the Developer
Companies are struggling to manage their security policies. They want to be able to change, develop, and manage their security policies from a central location. This reduces cost, and allows an organization to quickly determine their security policies throughout their applications.
Both Oracle WSM and OracleAS Web Services Security provide the ability to secure Web services. The WS-Security implementation within OracleAS Web Services was developed so that Web services can be secured by anybody who uses them. OracleAS Web Services Security is bundled with Oracle 10g Release 3 (10.1.3.1.0) Oracle Application Server, and supports the WS-Security 1.0 specification. It is ideal for deployments where Web services are deployed within the OC4J instance, and security is enforced locally by OC4J.
For large or enterprise-wide deployments where a number of Web services must be centrally managed and secured, Oracle WSM is recommended.
|
 Copyright © 2006, 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
