Friday Sep 16, 2011

SAML Identity switching policy - Limitations - 11g

This post from Edwin Beimond talks about the various SAML features in OWSM. However there is one quick thing I wanted to note: The inclusion of user attributes and roles is NOT supported when you are using the SAML Identity switching policy in the current release (11.1.1.5.0).

The documentation is not necessarily very clear on this front.

Note: This may change in a future release - however for now the above limitation exists.

Wednesday Sep 14, 2011

Follow up: Scope of OWSM Policy Repository, Policy Manager app - 11g

Quick follow up on this post. One of the customer's recently enquired whether we support Policy Manager in a different weblogic domain and Agents in a different weblogic domain. Basically the topology the customer was interested in is something along the lines shown below:

Cross Domain Policy Enforcement

The documentation is not very clear on whether this topology is supported and certified. There is some mention of this in this section in the OWSM documentation but talking to folks internally in OWSM - it appears this is not really supported/tested/certified. Hopefully we will see more clarity on this topic in future releases.

Global Policy Attachments - Inheritance rules - Part#2 - 11g

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:

  1. Overriding rule
  2. 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.

GPA all domains

Click here for a larger image.

Here are the WLST commands to setup GPA for the above scenario:

$>connect(...)
$>beginRepositorySession()
$>createPolicySet('all-domains-default-web-service-policies', 

'ws-service', 'Domain("*")')

$>setPolicySetDescription('Default policies for web 

services in any domain')

$>attachPolicySetPolicy('oracle/wss11_username_token_with_message_protection_service_policy')
$>validatePolicySet()
$>commitRepositorySession()

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:

overriding rules

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.

$>beginRepositorySession()

$>createPolicySet('generalledger-app-specific-web-service-policies', 
'ws-service', 'Application("GeneralLedger")')
$>setPolicySetDescription('Policies for web services in General ledger app')
$>attachPolicySetPolicy('oracle/wss11_x509_token_with_message_protection_service_policy')
$>validatePolicySet()
$>commitRepositorySession()

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:

additive inheritance rules

Click here 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.

Policy Attachment - GPA vs LPA - Best Practice - Part#1 - 11g

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.

Improved manageability

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?

  1. if you have not standardized on a security postured for your web services - then GPA is not very useful!
  2. 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).
  3. 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
  4. If a policy has expectations around how code is written by developers then GPA is not appropriate.
    • 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.
Here are some pointers to the OWSM documentation on GPA and LPA.

GPA: http://download.oracle.com/docs/cd/E21764_01/web.1111/b32511/policy_sets.htm#BABGJCED

LPA: http://download.oracle.com/docs/cd/E21764_01/web.1111/b32511/attaching.htm#CEGDGIHD

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.

Saturday Sep 10, 2011

Importing/Exporting OWSM Policies - 11g

Recently there was customer question around importing/exporting OWSM policies and I thought of addressing it in a wider context. There are basically two ways to import/export OWSM policies.

a) You can use FMWCTL to import/export policies

b) You can use WLST to import/export policies

Import/Export via FMWCTL
In FMWCTL you can import/export policies one at a time. This is described in the Security And Administrator's guide in the section "Managing Web Service Policies". Import is covered here. Export is covered here.

Import/Export via WLST

You can use WLST to perform bulk import/export of policies (and other documents). This is again described in the Security And Administrator's guide under the title "Importing and Exporting Documents in the Repository".

OWSM Policy Repository in JDeveloper - 11g

As mentioned in this post JDeveloper supports only attaching policies to Web Services. Quite a few people - are curious and have enquired from where exactly JDeveloper display's the list of OWSM Policies?

The answer: JDeveloper ships with an embedded OWSM Policy Repository. The embedded OWSM Policy Repository is a File based Policy Repository. You can check the location of this File Repository in JDeveloper. To do so Open JDeveloper, Click on the "Tools" menu, then click on "Preferences" menu item (Tools->Preferences). This will open a dialog as show below:

Viewing the location of the OWSM File Policy Repository in JDeveloper

Click here for a larger snapshot.

As you can see from the snapshot - the out of the box policies that ship with OWSM are installed as part of the JDeveloper in my case at the following location: "C:\Documents and Settings\pyamuna.ST-USERS\Application Data\JDeveloper\system11.1.2.0.38.60.17\DefaultDomain\oracle\store\gmds"

Note: This location will vary by platform (Windows vs. Linux).

Below is a snapshot of the contents of the folder "C:\Documents and Settings\pyamuna.ST-USERS\Application Data\JDeveloper\system11.1.2.0.38.60.17\DefaultDomain\oracle\store\gmds":

Folder contents of OWSM File Policy Repository

Note: Sometimes the folder will be empty. This is because the OWSM Policy Repository has not been initialized. You can trigger the initialization of the Policy Repository by trying to attach an OWSM policy to a Web Service. See this post by Jiandong on how to do this.

In future blog posts I will describe some of the features/options JDeveloper provides as it pertains to the OWSM Policy Repository and when to use these options - but hopefully this blog post solves the mystery of the OWSM Policy Repository in JDeveloper.

Update

in this blog post

Friday Sep 09, 2011

Logging SOAP messages to DB - 11g

Quick note: If you were a 10g OWSM customer and were using the feature that allowed Logging SOAP messages to DB - you might have realized that there is no equivalent functionality in 11g. In 11g, OWSM supports logging SOAP messages to a file but not to a DB. If you want to log messages to the DB, you have two options:

a) You can write a custom assertion that logs the messages to DB.

b) Build some kind of an automation tool that can take messages logged to the file and upload it to the DB.

If you build a custom assertion - I suggest you use the category for the assertion as "security/logging". This will enable you to add the custom assertion before and after a security assertion - similar to the out of the box "oracle/security_log_template".

If you do decide to write a custom assertion - you will need to take into consideration a couple of key aspects:

  • Performance implication - doing a synchronous write to the DB may be expensive - you may need some kind of an asynchronous mechanism to the write the message to the DB
  • DB growth - if you have logging of SOAP messages enabled in a system dealing with huge volume of transactions - then the growth of the DB is a significant issue that you will need to consider.

Thursday Sep 08, 2011

Vanishing Policy Attachments - Troubleshooting - 11g

It appears quite a few people run into the issue of the "vanishing policy attachments". Here are some typical scenarios where people run into the "vanishing policy attachments" issue:

Scenario#1:  Redeploying the app causes policy attachments to vanish

  1. User develops an app (say SOA Composite app).
  2. User deploys the app to WLS
  3. User secures the app by attaching an OWSM policy using FMWCTL
  4. User makes changes to the app in JDeveloper. User redeploys the app. The policy attached in step#3 has vanished!

Scenario#2: Moving the app from Dev->Test->Production causes policy attachments to vanish

  1. User develops an app (say SOA Composite app).
  2. User deploys the app to WLS in the Dev environment
  3. User secures the app by attaching an OWSM policy using FMWCTL
  4. User than "moves" the app to Test environment - by deploying the app to WLS running in Test environment. The policy attached in step#3 has vanished!

In both these scenarios - the vanishing of the policy attachments is expected behavior! If you make changes to the app post deployment - then you need to user either deployment plans to migrate/retain the changes or use import/export facilities based on the type of technology being used to develop web services.

The exact terminology used in Oracle FMW documentation varies from technology to technology. For ex: SOA Suite uses import/export, where as WLS uses deployment plan terminology. However irrespective of terminology the broad concept is the same - your original app (.ear or .war or .sar) is not modified directly when you do changes post deployment. So to retain the changes you need to do the following:

Revised Scenario#1:  Redeploying the app without losing policy attachments.

  1. User develops an app (say SOA Composite app).
  2. User deploys the app to WLS
  3. User secured the app by attaching an OWSM policy using FMWCTL
  4. User makes changes to the app in JDeveloper. 
  5. Export out the changes made to the app in step#3.
  6. User redeploys the app with changes made in step#4 + imports the changes saved in step#5.

Revised Scenario#2: Moving the app from Dev->Test->Product causes policy attachments to vanish

  1. User develops an app (say SOA Composite app).
  2. User deploys the app to WLS in the Dev environment
  3. User secured the app by attaching an OWSM policy using FMWCTL
  4. Export out the changes made to the app in step#3.
  5. User than "moves" the app to Test environment - by deploying the app + imports the changes saved in step#4 to WLS running in Test environment.

The section "Migrating Deployment Descriptors" in the Security And Administrator's Guide provides pointers on this subject.

Scope of OWSM Policy Repository, Policy Manager app

As i have mentioned in my previous posts Edwin has some really great posts on how to use OWSM policies. Another post that is really great is his post on SAML support in OWSM. However as I was going through his post I noticed a few things that I thought are worth clarifying/commenting...

First is the following comment:

For OWSM, every domain need to have it's own MDS repository to store all the OWSM policies and for SOA Suite you also need a soa-infra database repos.

Turns out this is not entirely accurate. For OWSM, the recommended topology is for "every domain to have it's own Policy Manager application", however it is not necessarily the case that each domain needs to have it's own Policy Repository (a.k.a MDS repository). In fact the Policy Manager app in Domain1 and Domain2 can share the same Policy Repository. This can be visualized as shown in in the below figure.

Multiple WLS Domains sharing the same OWSM Policy Repository

In future blog posts - I will try to provide some insight on when to use the various SAML features that Edwin presents in his blog post.

Wednesday Sep 07, 2011

Custom Policies & Custom Assertions - 11g

I came across this blog entry by Izzak de Hullu on OWSM Custom Policies; while I really appreciate Izzak's inventiveness and feedback and we are working on improving things here - I thought I should comment on a few things.

The first thing to note about the blog entry is you can actually sign only particular elements in the SOAP message rather than the entire body. While it is true that the out of the box policies only support signing/encrypting the body of the message, like I mentioned in the OWSM Concepts - 11g post - you can define new OWSM policies using FMWCTL.

So to achieve the use-case Izzak was attempting - To sign/encrypt particular elements - you can do the following:

  1. make a copy of "oracle/wss11_message_protection_service_policy" - let's call it "acme/wss11_message_protection_elements_service_policy". (See section "Creating a Web Service Policy from an Existing Policy"
  2. edit the policy to remove signing/encryption of the body and add elements to be signed and encrypted. This is described in the Security and Administrator's Guide unfortunately - it is in the appendix under the section "Predefined Assertion Templates". See Table titled "Request, Response, and Fault Message Signing and Encryption Settings"

The second and probably the more important thing to note is that Izzak is using some methods that are not exposed by the OWSM Extensibility Guide. This is not something I would recommend - as these methods are subject to change.

In a future post I hope to have a sample how to that describes this in detail.

OWSM Licensing - 11g

A quick note on OWSM Licensing - there are two options to license OWSM:

(1)    Get OWSM via SOA Suite, which includes full use license;

OR

(2) Get OWSM via AM Suite Plus, which includes a restricted use license. OWSM should be used in conjunction with another AM suite component.

Tuesday Sep 06, 2011

Attaching OWSM Policies - Best Practices - 11g

As mentioned in previous post - there are three ways to attach Policies in OWSM 11g.

a) at Design Time (DT) in an IDE - ex: JDeveloper

b) Post Deployment - using WLST or FMWCTL

One of the questions that pop up from time to time is around when to use what - in this post I provide some guidelines that can help in deciding which is the best methodology.

Before I actually layout some guidelines - we need to discuss a related feature supported in OWSM 11g - this relates to the fact that attaching a policy at DT does not prevent you from changing it post deployment. So (a) and (b) are not necessarily mutually exclusive. The reason OWSM provides this flexibility is in many organizations - administrators (either app administrators or security administrators) decide on the security posture and hence the ability to change the security posture by changing the policy of a Web Service or Web Service Client is an important consideration [1].

So if your organization is more attuned to the process of standardizing security upfront and communicating it to your developers then developers can secure it at DT, test it early to ensure all aspects are working before the app gets deployed to a testing, staging, production environments. In general I would recommend some level of testing with security enabled in your DT environment. (a) is helpful in those scenarios.

(b) is relevant in two scenarios:

i) you have unsecure apps that need to be secured by the administrators post deployment.

ii) you have secure apps but they don't adhere ot the security guidelines standardized by the organization and hence you need to change the policy attached to the WS/WS Client.

Using WLST vs. FMWCTL:

WLST is more suited if you would like to script things out (in addition some administrators like command line tooling while others prefer a Web based user interface).

FMWCTL is more suited for people who prefer a Web based user experience or for non-scripting scenarios.

In future blog posts I will discuss guidelines around when to use Direct Policy Attachments (or Local Policy Attachments) vs. Global Policy Attachments (GPA).

Notes:

[1] In 11.1.1.5.0 - WLS JAX-WS Client support only a programmatic model of attaching the policy to the client app. In this scenario - one cannot change the policy post deployment.

Handling Passwords in OWSM - Best Practices - 11g

I came across some excellent blogs on the net that talk about OWSM and how to use OWSM to secure your web services/web service clients.

Here are some examples that I see on the net:

http://biemond.blogspot.com/2010/08/things-you-need-to-do-for-owsm-11g.html by Ediwin Beimond.

http://blogs.oracle.com/wssi/entry/securing_weblogic_web_servcies_with  by Jiandong Guo

Edwin Beimond has some excellent posts in terms of providing a detailed step-by-step How To describing how to use various OWSM policies. However one of things I have noticed is that people end up specifying passwords in the clear as part of their code snippets.

This is something I would strongly discourage customer's from adopting. Passwords in the clear in code is a recipe for security vulnerabilities. It also results in brittle code - if the passwords change - you need to change code.

Oracle FMW provides a credential store framework (CSF) to enable storing passwords in a secure fashion and I encourage people to use CSF rather than specifying passwords in the clear.

In future blog posts I will discuss how to use CSF instead of clear text passwords.

OWSM Concepts - 11g

Jiandong has posted a number of articles introducing OWSM 11g at http://blogs.oracle.com/wssi/.

This post elaborates on some of the aspects discussed in those posts. There are three aspects to securing a web service using OWSM

  1. Defining Policies
  2. Attaching Policies
  3. Setup Configuration required for Policies
(Note: While this post focuses on security, this is true for other policies like WS-RM, etc as well)

Defining Policies

Policies in OWSM are defined generically without context i.e. in general they are not App specific. There are some types of security policies that tend to be App specific - we will blog about this in a future post.

How to define policies?

You typically define policies using FMWCTL (Fusion Middleware CTL). The Security And Administrators Guide provides detailed documentation on how to define policies. (See Section Managing Web Service Policies ).

A Policy can be composed of a number of "Assertions". Typically you will have atleast one Assertion in a Policy.

Attaching Policies to Policy Subjects

Once a Policy is defined - you can "attach" the Policy to a Policy Subject. A Policy Subject is either a Web Service or a Web Service Client. OWSM supports a variety of Web Services [ex: Oracle Infrastructure Web Services, SOA Web Services, ADF BC Web Services, OSB Proxy Service, WLS JEE JAX-WS, Oracle WebCenter WSRP, etc] and Web Service Clients [ex: SOA References, ADF Web Service Data Control (WSDC), OSB Business Service, WLS JEE JAX-WS Clients, WebCenter Portal, etc]

How to attach Policies?

There are three ways to attach OWSM Policies:

a) Via IDE's - ex: JDeveloper

b) Via Command Line Tooling - ex: WLST

c) Via Web based user interface - ex: FMWCTL

(b) and (c) are discussed in detail in the Security And Administrator's guide. Specifically see Section "Attaching Policies to Web Services" for details.

Note: WLST is not support for OSB and WLS Web Services/Web Service Clients as of 11.1.1.5.0.

Setup Configuration required for Policies

 Most Policies (esp. "security policies";) require additional configuration. For example:

  1. Message protection policies require Keystore setup.
  2. Passwords require OPSS Credential store setup,
  3. Authentication policies require Identity Store setup
  4. WS-Trust based policies require STS

This is discussed in detail in the Section "Setting Up Your Environment for Policies".

From our interactions with customers, support, etc - it appears most people seem to trip up on the last aspect. In future blog posts we will elaborate on some of the concepts introduced in this blog post as well as describe in detail the "Setting Up Your Environment for Policies".

About

In this blog I will discuss mainly features supported by Oracle Web Service Manager (OWSM).

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today