Use the questionnaire provided in this chapter to help you determine which security policies are most appropriate for your Web service. This chapter also provides summaries of the predefined security policies included with the current release.
This chapter contains the following sections:
Section 3.3, "Which OWSM Policies Are Supported for Java EE Web Services?"
Section 3.4, "Which OWSM Policies Are Supported for RESTful Web Services?"
Section 3.6, "Which OWSM Policies Are Supported for Identity Context?"
Section 3.7, "Which Policies Support WS-SecureConversation?"
Use the following series of questions to help you identify the security policies that best meet your requirements:
What are the basic requirements of your security policy? Decide if you need to only authenticate users, or if you only need message protection, or if you need both.
Do you require authentication only? If yes, then go to step 2.
Do you require authorization only? If yes, then see Chapter 10, "Configuring Authorization".
Do you require authentication and authorization? If yes, then go to step 3.
Do you only require message protection? If yes, then see "Security Policies—Message Protection Only".
Do you require both authentication and message protection? If yes, then go to step 4.
If you only require authentication, then there are two basic questions you need to consider:
Where will the token be inserted? Will the token to be inserted in the transport layer or in a SOAP header?
Do you need to use a particular type of token? The supported credentials for authentication-only policies are username/password, SAML, and Kerberos tokens. Authentication-only policies are described in Section 3.2.1, "Authentication Only Policies".
If you require authentication and authorization, then you need to consider the following:
Review the considerations provided for authentication in step 2.
Review Chapter 10, "Configuring Authorization" for more information about authorization policies.
If you require both authentication and message protection, then you need to consider the following:
Will message protection be handled in the transport layer? If yes, then there are four sets of policies to choose from: Username over SSL, SAML over SSL (Sender-Vouches), SAML over SSL (Token Bearer), and HTTP token over SSL. Kerberos over SSL is also available via a custom policy.
In one set of policies (wss_http_token_over_ssl_client_policy and wss_http_token_over_ssl_service_policy) authentication is also handled in the transport layer. For the other three polices, authentication takes place in the SOAP header.
If you are using the WS-Security V1.0 or V1.1 standard, then both authentication and message protection occur in the SOAP header. There are five pairs of policies supporting the following tokens: username/password, SAML, X.509 certificates, and Kerberos.
For more information, see "Security Policies—Messages Protection and Authentication".
OWSM includes many different authentication policies, and it might not be obvious which one best suites your needs.
Table 3-1 describes selected authentication policies and when you might want to use them. In Table 3-1 the policy names are shown with wildcards (for example, "*username_token*") to indicate all policies that have username_token in their name.)
Table 3-1 Choosing the Right Authentication Policy
| Policy Type | Description |
|---|---|
|
*username_token* |
For these policies, the client needs to send the username and password to the Web service. The password must be made available to the client in the credential store. This type of policy is useful for identity switching, in which a client needs to connect to a Web service with an application identifier that is different from the actual end user name. It is the simplest of the authentication policies, and therefore compatible with the widest variety of third party clients. |
|
*saml* |
For these policies, the client needs to send a SAML assertion that contains the user name. There are variants of SAML, including the following:
|
Because SAML sender vouches are username token are among the most used policies, OWSM offers OR group policies combining these two, such as oracle/wss_saml_or_username_token_service_policy. In most situations Web services should use this policy. This is policy is also a perfect candidate for global policy attachment.
OWSM offers three levels of confidentiality and integrity:
No confidentiality and integrity — Confidentiality and integrity require cryptography, which consumes computing resources. In messages exchanged between middleware servers in a fire walled private network, there is no need to pay the price for confidentiality and integrity. The OWSM policies that do not have confidentiality and integrity do provide authentication through username token or SAML.
SSL based confidentiality and integrity — SSL provides transport level confidentiality and integrity. With SSL you need to change your endpoints to use HTTPS, and make sure your clients talk to the HTTPS endpoints.
Message Security based confidentiality and integrity — Message security offers much lower performance than SSL, but it has some advantages over SSL:
Unlike SSL, where the message stops being secure at the SSL termination point (which can be a load balancer, Oracle HTTP Server, or J2EE container) with message security the message remains secure all the way to the application.
With SSL, the security is at the container level. That is, all Web services running on a container must share the same key. With message security, although the default is to share the same key throughout the domain, it is also possible to override the key on a per-Web-service basis.
There are two versions of message security offered in OWSM: wss10 and wss11. wss11 is an improvement over wss10 because every client does need to have its own client key, which is required for Wss10. (In certain policies such as SAML sender vouches, the client key is required in wss11 as well.)
wss11 is also faster because it requires fewer asymmetric key operations. However wss10 offers wider compatibility: some clients work with wss10 only.
Use wss11 policies unless you need to support a client that can use wss10 only.
The following sections summarize the predefined security policies, based on the type of security they provide and whether the policy is enforced at the transport layer or SOAP header. For more information about the predefined policy categories, see "Policy Categories" in Understanding Oracle Web Services Manager. For full descriptions of the policies, see Chapter 18, "Predefined Policies."
Security Policies
The following authentication only policies are provided for SOAP and RESTful Web services.
Table 3-3 summarizes the security policies that enforce authentication only for SOAP and RESTful Web services.
Table 3-2 Authentication Only Policies—SOAP and RESTful Web Services
| Client Policy | Service Policy | Authentication Transport |
|---|---|---|
|
Yes |
||
|
N/A |
Yes |
|
|
Yes |
||
|
Yes |
||
|
Attach one of the following:
To support HTTP OAM security, you must configure OAM Webgate to intercept the request. For more information, see "oracle/multi_token_rest_service_policy". |
Yes |
|
|
Attach one of the following:
To support HTTP OAM security, you must configure OAM Webgate to intercept the request. For more information, see "oracle/multi_token_over_ssl_rest_service_policy". |
Yes |
Table 3-3 summarizes the security policies that enforce authentication only for SOAP Web services and indicates whether the token is inserted at the transport layer or SOAP header.
Table 3-4 summarizes the policies that enforce message protection only, and indicates whether the policy is enforced at the transport layer or SOAP header.
Table 3-5 summarizes the policies that enforce both message protection and authentication but do not conform to the WS-Security 1.0 or 1.1 standard. The table indicates whether the policy is enforced at the transport layer or SOAP header.
Table 3-5 Message Protection and Authentication Policies
Table 3-6 summarizes the security policies that enforce authorization, and indicates whether the policy is enforced at the transport layer or SOAP header.
Table 3-7 summarizes the WS-Trust policies.
| Client Policy | Service Policy | Authentication Transport | Authentication SOAP | Message Protection Transport | Message Protection SOAP |
|---|---|---|---|---|---|
|
No |
No |
No |
No |
||
|
oracle/wss_sts_issued_saml_bearer_token_over_ssl_client_policy |
oracle/wss_sts_issued_saml_bearer_token_over_ssl_service_policy |
Yes |
No |
Yes |
No |
|
oracle/wss11_sts_issued_saml_hok_with_message_protection_client_policy |
oracle/wss11_sts_issued_saml_with_message_protection_client_policy |
No |
Yes |
No |
Yes |
|
oracle/wss11_sts_issued_saml_with_message_protection_client_policy |
No |
Yes |
No |
Yes |
The MTOM attachment policy included in the current release is listed below.
Please note the following:
If you configure MTOM from Fusion Middleware Control by attaching the oracle/wsmtom_policy policy (either via local or Global Policy Attachment), the endpoint throws a fault if the request is not MTOM encoded. The MTOM policy rejects inbound messages that are not in MTOM format and verifies that outbound messages are in MTOM format. In this use, requests must be MTOM-enabled.
If you configure MTOM for an ADF BC Web service outside of Fusion Middleware Control, such as by editing the MTOM-enabled switch in oracle-webservices.xml or by directly adding the @MTOM annotation to the Web service, the endpoint can accept MTOM requests but does not return a fault if the request is not MTOM encoded. In this use, requests might be MTOM-enabled, but there is no requirement that they must be.
The Reliable Messaging policies included in the current release are listed below.
These policies provide the ability to effectively disable a policy attached globally in a policy set. There are no configuration properties available for these policies. All of these policies use the same no behavior assertion.
Only a subset of OWSM policies are supported for Java EE Web services. Specifically, you can attach to WebLogic JAX-WS Web services the OWSM security policies in the following categories:
Authentication only
Message protection only
Message protection and authentication
Authorization
WS-Trust
WS-SecureConversation
OWSM policies in the following categories are not currently supported for WebLogic JAX-WS Web services:
Atomic Transactions
Configuration
Management
MTOM attachment
No behavior
Reliable messaging
SOAP Over JMS Transport
WS-Addressing policies
Only a subset of OWSM security policies are supported for RESTful Web services, as outlined in Table 3-8.
Table 3-8 OWSM Security Policies Supported for RESTful Web Services and Clients
| Security | Supported Policies |
|---|---|
|
Authentication Policies |
Authentication policies defined in Table 3-2. |
|
Authorization |
|
Note:
You can also attach a SPNEGO token policy that you create using the oracle/http_spnego_token_service_template assertion template. For more information, see "Configuring Kerberos With SPNEGO Negotiation".
The predefined policies that require you to configure SSL are as follows:
oracle/wss_http_token_over_ssl_service_policy
oracle/wss_http_token_over_ssl_client_policy
oracle/wss_saml_token_bearer_over_ssl_server_policy
oracle/wss_saml_token_bearer_over_ssl_client_policy
oracle/wss_saml_token_over_ssl_service_policy
oracle/wss_saml_token_over_ssl_client_policy
oracle/wss_username_token_over_ssl_service_policy
oracle/wss_username_token_over_ssl_client_policy
In addition, you can create a new policy that requires SSL by using the following templates:
oracle/wss_http_token_over_ssl_service_template
oracle/wss_http_token_over_ssl_client_template
oracle/wss_saml_token_bearer_over_ssl_service_template
oracle/wss_saml_token_bearer_over_ssl_client_template
oracle/wss_saml_token_over_ssl_service_template
oracle/wss_saml_token_over_ssl_client_template
oracle/wss_sts_issued_saml_bearer_token_over_ssl_client_template
oracle/wss_sts_issued_saml_bearer_token_over_ssl_service_template
oracle/wss_username_token_over_ssl_service_template
oracle/wss_username_token_over_ssl_client_template
See Chapter 19, "Predefined Assertion Templates" and Chapter 18, "Predefined Policies" for more information on these assertions and policies.
The predefined policies that require you to configure two-way SSL are as follows:
oracle/wss_saml_token_over_ssl_client_policy
oracle/wss_saml_token_over_ssl_service_policy
oracle/wss_username_token_over_ssl_client_policy, when mutual authentication is selected.
oracle/wss_username_token_over_ssl_service_policy, when mutual authentication is selected.
oracle/wss_http_token_over_ssl_client_policy, when mutual authentication is selected.
oracle/wss_http_token_over_ssl_service_policy, when mutual authentication is selected.
In addition, you can create a new policy that requires two-way SSL by using the following templates:
oracle/wss_saml_token_over_ssl_client_template
oracle/wss_saml_token_over_ssl_service_template
OWSM supports the Identity Context feature, as described in "Propagating Identity Context with OWSM".
The following SAML policies support the propagate.identity.context configuration property:
oracle/http_saml20_token_bearer_service_policy and oracle/http_saml20_token_bearer_client_policy
oracle/http_saml20_token_bearer_over_ssl_service_policy and oracle/http_saml20_token_bearer_over_ssl_client_policy
oracle/wss_saml_or_username_token_service_policy
oracle/wss_saml_or_username_token_over_ssl_service_policy
oracle/wss_saml_token_bearer_over_ssl_service_policy and oracle/wss_saml_token_bearer_over_ssl_client_policy
oracle/wss_saml_token_over_ssl_service_policy and oracle/wss_saml_token_over_ssl_client_policy
oracle/wss_saml20_token_bearer_over_ssl_service_policy and oracle/wss_saml20_token_bearer_over_ssl_client_policy
oracle/wss_saml20_token_over_ssl_service_policy and oracle/wss_saml20_token_over_ssl_client_policy
oracle/wss10_saml_token_service_policy and oracle/wss10_saml_token_client_policy
oracle/wss10_saml_token_with_message_integrity_service_policy and oracle/wss10_saml_token_with_message_integrity_client_policy
oracle/wss10_saml_token_with_message_protection_service_policy and oracle/wss10_saml_token_with_message_protection_client_policy
oracle/wss10_saml_token_with_message_protection_ski_basic256_service_policy and oracle/wss10_saml_token_with_message_protection_ski_basic256_client_policy
oracle/wss10_saml20_token_service_policy and oracle/wss10_saml20_token_client_policy
oracle/wss10_saml20_token_with_message_protection_service_policy and oracle/wss10_saml20_token_with_message_protection_client_policy
oracle/wss11_saml_token_with_message_protection_service_policy and oracle/wss11_saml_token_with_message_protection_client_policy
oracle/wss11_saml_or_username_token_with_message_protection_service_policy
oracle/wss11_saml20_token_with_message_protection_service_policy and oracle/wss11_saml20_token_with_message_protection_client_policy
OWSM includes the following policies for which WS-SecureConversation is enabled by default:
oracle/wss11_saml_token_with_message_protection_wssc_client_policy
oracle/wss11_saml_token_with_message_protection_wssc_service_policy
oracle/wss11_saml_token_with_message_protection_wssc_reauthn_client_policy
oracle/wss11_saml_token_with_message_protection_wssc_reauthn_service_policy
oracle/wss11_username_token_with_message_protection_wssc_client_policy
oracle/wss11_username_token_with_message_protection_wssc_service_policy
oracle/wss11_x509_token_with_message_protection_wssc_client_policy
oracle/wss11_x509_token_with_message_protection_wssc_service_policy
oracle/wss_username_token_over_ssl_wssc_client_policy
oracle/wss_username_token_over_ssl_wssc_service_policy
In addition to these policies, policies based on many of the predefined assertion templates also support WS-SecureConversation. For more information, see Chapter 19, "Predefined Assertion Templates."