Policy Attachment - GPA vs LPA - Best Practice - Part#1 - 11g
By Prakash Yamuna-Oracle on Sep 14, 2011
In a previous post I briefly mentioned about the fact that in OWSM 11g - we support Global Policy Attachments (GPA) and Local Policy Attachments (LPA) or sometimes also referred to as Direct Policy Attachments (DPA). In this post - I will provide some best practice guidelines on when to use GPA vs. LPA.
For those who are not familiar - in the case of LPA you attach it to a WSDL Port - so the policy applies to WSDL Port. GPA allows you to attach a policy to more coarse grained entities - ex: it can be to a Weblogic Domain - in which case the policy applies to all WSDL Ports running in that weblogic domain. Or the policy can be attached to an application - in which case the policy applies to all WSDL Ports that are part of that application (ex: ear). etc...
So the first main difference b/w GPA and LPA is the granularity. So when would one use GPA? Basically two scenarios:
a) You want a "Secure by Default" story
b) Ease of management for large deployments.
Secure by Default
So what do I mean by "Secure by Default"? Let's say you develop a web service in your favorite IDE. You can secure it at Design Time. However let's say you decide not to secure it at design time. Now the app is deployed - this app is not secure unless somebody goes and secures it post deployment in EM or via WLST. If there are no strict controls and processes in place - that ensures that app is secured before it is made available to the outside world - then you have a potential for vulnerability in that the app is running unsecured.
Let's say you have a large deployment - 100's of web services - lots of WLS servers, multiple weblogic domains, etc. In this case going and securing each of the 100's of web services can be tedious, time-consuming, and error prone - especially if you want to ensure there are no web services that are unsecured. In such cases, if you have standardized on the security posture of your web services - GPA can be a life saver!.
You can define a GPA that says "all web services (WSDL Port) in all domains" in your deployment use let's say wss11_username_token_with_message_protection_service_policy!
Now whenever a new app is deployed to one of the domains in your deployment - it will "automatically inherit" the oracle/wss11_username_token_with_message_protection_service_policy and you don't have to go into individual web service and secure it. Let's say a year from now - you decide to change the default security posture to say all oracle/wss11_x509_token_with_message_protection_service_policy - then all you need to do is change it your GPA definition - in one place and all the web services in your deployment will be secured with this new policy!
When should you not use GPA?
- if you have not standardized on a security postured for your web services - then GPA is not very useful!
- Using GPA for role based authorization policies is not very useful. Typically different web services will be accessible by different roles. (Note: It would be ok to use GPA for permission based authorization policies).
- If your policy has app specific aspects - then GPA is not appropriate.
- If you want specific parts of the message to be signed or encrypted as discussed in this post
- Ex: Using GPA for MTOM or WS-RM may not be appropriate. Not all web services support attachments - especially MTOM attachments. Also in many cases WS-RM or MTOM may require some coding considerations by developers.
Note: The documentation uses the terminology PolicySet for GPA. PolicySet is the underlying implementation model for supporting Global Policy Attachments!
GPA is extremely powerful - but you need to really understand the pros & cons before you decide to use this feature. In future posts - I will discuss:
a) some of the inheritance rules, etc associated with GPA and also what happens when you have GPA and LPA in a deployment or what happens when you want to mix policies from different categories - ex: Security and WS-RM.
b) When to combine different granualrities
c) Life-cycle aspects of GPA and how it differs from LPA.