In this blog post i briefly mentioned about GPA vs. LPA and when to use GPA. As I mentioned the key difference between GPA and LPA is around granularity (or scope of the policy attachment). So what are inheritance rules - if we define GPA that applies to say "all domains" vs. a GPA for "domain1" vs. a GPA for "app1", etc then the inheritance rules determine which policy get's enforced for a particular web service.
Broadly speaking there are two types of inheritance rules:
- Overriding rule
- Additive rule.
So here is a simple scenario.
Scenario#1: We have a deployment with two weblogic domains (Domain#1, Domain#2). We want to secure all web services (SOA, ADF, etc) in this deployment with wss11_username_token_with_message_protection_service_policy as shown in the figure below.
Click here for a larger image.
Here are the WLST commands to setup GPA for the above scenario:
$>setPolicySetDescription('Default policies for web
services in any domain')
See here for detailed description of these commands.
GPA Overriding rules
Scenario#2: If we now want to consider a scenario where in for a particular app (let's say "GeneralLedger" needs to be secured with oracle/wss11_x509_token_with_message_protection_service_policy) - then we need to define a new GPA. This is shown in figure below:
Click here for a larger image.
Here are the set of commands to define the GPA for GeneralLedger app to be secured with oracle/wss11_x509_token_with_message_protection_service_policy.
$>setPolicySetDescription('Policies for web services in General ledger app')
In the scenario above - for Web Services in GeneralLedger the policy oracle/wss11_x509_token_with_message_protection_service_policy will be applied. Thus the application specific GPA overrides the deployment wide GPA. So we have the first rule which is basically that the more specific GPA overrides the more generic GPA.
GPA Additive rules
Scenario#3: Now let's consider a scenario where an application with a single WS (say "Reliable & Secure WS" - for lack of a better name!) want's security and WS-RM. Also we want the security to be the same as the deployment wide posture i.e. the app needs to be secured with oracle/wss11_username_token_with_message_protection_service_policy. In this scenario - all you need to do is attach oracle/ws_reliable_messaging_policy via LPA to the "Reliable & Secure WS". In this case OWSM recognizes that the "category" of the policy defined at the GPA level is "security" and specifically it is "authentication" and "message protection" subcategories under security and this in this case adds the policies such that the policies applied for "Reliable & Secure WS" is both oracle/wss11_username_token_with_message_protection_service_policy and oracle/ws_reliable_messaging_policy.
This is depicted in the figure below:
for a larger image.
Since the inheritance rules change based on the "category" of the policy and it may not always be clear as to which policy is being applied to a particular web service - OWSM provides what I call the "Effective Policy View" i.e. the set of policies that will be applied to a Web Service after applying of the inheritance rules I just described above. You can view the "effective policies" either in EM or via WLST. See this section in the documentation for a description around "Effective Policies".
Note: GPA is currently as of 11gR1 PS4 not supported for WLS WS and OSB.