This section contains the following topics:
Domain-based Policy Management Overview
How to Identify a Web Service Resource by Agent, Realm, and Rule
Guided Example: Create Security Policies from a WSDL File
Domain-based policy management using policy domains and domain objects allows you to perform manual configuration of security policies for web service resources. Domain-based policy management is required to create policies that implement content-based authorization using variables.
The remainder of this chapter gives advice about how to best define domain-based policies to protect web service resources. The following chapters describe all the policy object types and how to configure them in detail.
The Resource field in a CA SiteMinder® Web Services Security rule specifies the resource that is the subject of the rule. The complete resource specification (shown by the Effective Resource field on the Rule dialog box) is a concatenation of the values of the Agent, the Resource Filter of the parent realm (or realms in a nested realm environment), and the Resource field of the rule itself:
[agent] [realm_resource_filter] [rule_resource]
Specifies a SiteMinder WSS Agent that monitors a server or gateway that contains one or more realms of protected web service resources.
Specifies a string that specifies the resources covered by the realm. If the realm is a top-level realm, specify the resources relative to the server that serves up the files or application. If the realm is nested, specify the resources relative to the parent realm.
Specifies a string or regular expression that specifies the resources to which the rule applies. Specify the resources relative to the realm containing the resource. You can use wildcards (for example, "*") to broaden the specification of a rule.
By default, the SiteMinder WSS Agent for Web Servers identifies a web service being requested by extracting the binding URL and name of the web service and concatenating them as follows:
[agent] [/web_service_URL] [/web_service_name]
However, the SiteMinder WSS Agent for Web Servers can be configured to perform fine-grain resource identification, in which case it additionally identifies the web service operation being requested:
[agent] [/web_service_URL] [/web_service_name] [/web_service_operation]
This topic describes how the following SiteMinder WSS Agent types identify web service resources:
If a request is received over HTTP(S) transport, these SiteMinder WSS Agent types identify the web services being requested by extracting the binding URL, the name of the web service, and the name of the web service operation and concatenating them as follows:
[agent] [/web_service_URL] [/web_service_name] [/web_service_operation]
If a request is received over JMS transport, these SiteMinder WSS Agent types identify the web services being requested by extracting the JMS queue or topic name and the name of the web service operation and concatenating them as follows
[agent] [/queue_or_topic_name] [/web_service_operation]
Coarse-Grain Resource Identification Over HTTP Example
Say you want to protect a resource with the following properties.
To protect ExampleSearchService, configure the following:
Fine-Grain Resource Identification Over HTTP Example
Say you want to protect a resource with the following properties.
To protect ExampleSearchService, configure the following:
Fine-Grain Resource Identification Over JMS Example
Say you want to protect a resource with the following properties.
To protect ExampleSearchService, configure the following:
By default a realm is created in a protected state. In most cases, you should use protected realms instead of changing a realm to an Unprotected state. In a protected realm, all resources are protected against access. To allow access, a rule must be defined, then included in a policy.
When you create a realm in an unprotected state, you must configure rules before CA SiteMinder® Web Services Security protects the resources in the realm. If you create a rule for resources in the unprotected realm, only the specified resources are protected. Once the resource is protected, the rule must be added to a policy to allow users to access the resource. You may want to use an unprotected realm if only a subset of the resources in a realm need to be protected from unauthorized access.
The following is an example of the actions required when setting up an Unprotected realm:
|
Action |
Protection State |
|
Create unprotected realm called Realm1 with the Resource Filter: /dir. |
Resources contained in /dir and subdirectories are not protected. |
|
Create Rule1 in Realm1 for the resource: getCachedQuote.asp. |
The /dir/getCachedQuote.asp resource is protected, but the rest of the contents of /dir are not protected. |
|
Create Policy1 and bind Rule1 and User1 to the Policy. |
User1 can access /dir/getCachedQuote.asp. All other users cannot access the protected file. |
Deployed web services are typically described in an associated Web Services Description Language (WSDL) file. One way of getting started creating security policies using tradtional policy management, especially in terms of creating realms, rules, and the resource mappings they define, is to work from the WSDL file associated with a deployed web service.
To create security policies from the WSDL file for a deployed web service
In the following snippet from ExampleSearch.wsdl, the web service port to secure is ExampleSearchPort. This port is bound to the URL http://api.example.com/search/beta2.
<service name="ExampleSearchService">
<port name="ExampleSearchPort" binding="typens:ExampleSearchBinding">
<soap:address location="http://api.example.com/search/beta2"/>
</port>
</service>
In the following snippet, the three web service operations to secure are doGetCachedPage, doSpellingSuggestion and doExampleSearch. All these three operations are children of ExampleSearchPort which has been secured by the realm named ExampleSearchRealm.
<portType name="ExampleSearchPort">
<operation name="doGetCachedPage">
<input message="typens:doGetCachedPage"/>
<output message="typens:doGetCachedPageResponse"/>
</operation>
<operation name="doSpellingSuggestion">
<input message="typens:doSpellingSuggestion"/>
<output message="typens:doSpellingSuggestionResponse"/>
</operation>
<operation name="doExampleSearch">
<input message="typens:doExampleSearch"/>
<output message="typens:doExampleSearchResponse"/>
</operation>
</portType>
Resource Filter: “/Web Service Operation Name"
Action: Post, ProcessSOAP and ProcessXML Web Agent actions
|
Copyright © 2013 CA.
All rights reserved.
|
|