Thursday Feb 07, 2013

When to use Oracle STS (OSTS)?

I have been meaning to do a blog post on this front for quite sometime but just haven't had the cycles. So this a very rushed blog post - please excuse typos!!

The basic question that seems to come up is when to use an STS in general and OSTS in particular. So here are my thoughts on the matter.

To me there are - three main scenarios for using a STS:

  • Token Exchange/Conversion
  • Federation
  • Centralized Trust

In this post I will cover Token Exchange and Federation very briefly.

Token exchange/conversion

So the first set of scenarios is around the need to be able to exchange one kind of token with another type of token. Ex: You want to exchange a Kerberos Token with a SAML token. Here is a picture that demonstrates this scenario (click on the image for a large image):


STS Token Exchange Use-case

In the  above scenario a customer has a Desktop Application (ex: Say Outlook or some other .NET Web Service) that is talking to a backend Web Service let's say hosted on Oracle Fusion Middleware that can accept SAML Token.

User "joe" logs into his Desktop and a Kerberos Ticket is created. When user opens the Desktop application and performs an operation this results in a backend web service call and we want to propagate the identity of "joe" to the backend application. However the token we have is a Kerberos Token on the client side and the backend Web Service only accepts a SAML token. One can use an STS to do a token conversion or token exchange (assuming the STS is capable of such a conversion).

Web Service Federation

The second scenario where a STS is very useful and probably the most important scenario in my mind is when you need to do Federation. For those of you who are not familiar with Federation - I suggest reading up on Federation in general and Web Service Federation in particular. The picture below depicts this use-case.

STS - Federation Use-case

The use-case is similar to a Token Exchange use-case. We have a Desktop Application (say Outlook) that needs to invoke a backend Web Service. However the backend Web Service is running in the Cloud (Public or Private Cloud).

The key issue here is that the user "joe" is unknown in the Cloud.

There is a good reason why the user "joe" is unknown in the Cloud. Since an application running in the cloud may be used by multiple customers say "Acme Inc" or "Foobar Inc" both of which may user called "joe" the Cloud cannot have a single user named "joe" in it's Directory instead it would need to distinguish "Acme Inc" user "joe" (let's call him "acme.joe" ) from "Foobar Inc" user "joe" (let's call him "foobar.joe" ).

So now in the Cloud we actually have two users "acme.joe" and "foobar.joe" - so the Desktop Application (running within Acme Inc) needs to map "joe" to "acme.joe" - before it talks to the Cloud. This mapping is where an STS comes in handy! as shown in the picture.

So not only are we converting the token from Kerberos to SAML we are also now mapping "joe" to "acme.joe" in the STS.

Notes:
  1. The picture depicts Oracle Public Cloud - but the concept applies to any Cloud (Public/Private) or in fact across Partner systems.
  2. The picture depicts Fusion CRM - but the concept applies to any Web Service
  3. I make no guarantees that what is shown in the picture above is necessarily what is implemented in the Oracle Public Cloud and I have used the example for purely illustrative purposes!

In a future blog post I will elaborate further on some of the scenarios and also the Centralized Trust scenario.

Finally - one last parting shot - the scenarios and use-cases for an STS and OSTS are fairly extensive and in this blog post - I am trying to illustrate some very simple scenarios. Please consult the Oracle STS documentation for all the features.

Tuesday Mar 13, 2012

How To - OWSM and WLS WS-Security Interop - 11g

Here is another How To that provides a detailed step by step guide for getting OWSM to Interop with WLS WS-Security using the Username Token with message protection policy.

Happy Reading!

Update:

A few things I forgot before I posted this entry:

  • The OWSM interop guide provides a high level overview of the steps involved in achieving this interop - however it does not provide a detailed step by step instructions and so I thought I would provide a more detailed How To for customers who are having problems following the interop guide. http://docs.oracle.com/cd/E23943_01/web.1111/e16098/interop_wls.htm#BABCCHIJ
  • As the doc makes it clear you only need to configure the "Confidentiality Key" - however in the How To I cover configuring both "Confidentiality and Signing Key". You can safely skip the steps relating to configuring the "Signing Key".
  • I have simplified things to a large extent in terms of the keystore setup. This setup is not always practical from a production setup perspective. However since I have not had a chance to post more on keystores, credential stores, etc - I have tried to keep it simple here. I hope to post more on the topic of Keystores, certificates, credentials, credential stores, etc in a future post.


Monday Mar 12, 2012

How To - Field level encryption using OWSM 11g

Finally I have figured out a mechanism to host some How To's that I can share on this blog and here is my first How To on Field level encryption (partial encryption) using OWSM 11g.

I hope to post more How To's in the future...

Comments welcome.

PS:

A few bookkeeping rules:

a) This is not part of official documentation from Oracle.

b) The steps may change from one version to another - so please keep that in mind. I have not tested this against all versions of the product - but I expect it to work with the versions I mentioned in the pdf.

Tuesday Dec 13, 2011

Time travel for OWSM Administrators - 11g

I liked the title of this post from Antony Reynolds so much that I borrowed it for my post! Antony's post talks about the versioning support in OWSM 10g. This post is about the versioning support in OWSM 11g.

Here I will take a simple example, let's say a customer has decided to standardize on Basic192 as the algorithm suite to be used for all message protection policies. The customer can do so by editing - let's say the oracle/wss10_saml_token_with_message_protection_service_policy.

The default value is Basic128 for the OOTB policy that ships with OWSM. Now we have two versions of the oracle/wss10_saml_token_with_message_protection_service_policy.

This is illustrated in the picture below (Click on the images for a larger image):


You can view the version history for any policy by clicking on the "version history" link.

The version history page looks as shown below:

policy version history

You can view the individual versions by clicking on the "view" button in the above image. Below is the version#1 of the oracle/wss10_saml_token_with_message_protection_service_policy.


 Version#2 of the oracle/wss10_saml_token_with_message_protection_service_policy is shown below:


Like in OWSM 10g - you can revert or activate an older version if you realize that the changes that were made were not satisfactory for any reason.

Limitations:

It is important to note some of the limitations that exist in terms of the versioning support in OWSM 11g.

  1. Enforcement does not take policy version into consideration i.e. enforcement is always based on the latest version (in the above case version#2).
  2. While OWSM maintains the version history it does not provide any tooling to view the differences b/w the two versions. However for each version OWSM does maintain information about who edited the policy and when - hence once can talk to person who edited the policy to find out the changes.
  3. Currently versioning is supported only for policies. Versioning is not supported for Assertion templates and Global Policies.
Detailed documentation on the OWSM 11g versioning support can be found here in the Security and Administrators Guide for Web Services.

Sunday Oct 09, 2011

Fusion Apps and OWSM - 11g

Now that Fusion Apps 11g is generally available - I thought I would share some experiences in terms of how Fusion Apps leverages OWSM for it's Web Services security needs.

Fusion Apps is built on Fusion Middleware and mentioned in the various keynotes - there were a few key design principles that played a significant role. These are:

a) Secure By Default

b) Externalize Security from Applications and Declarative Security via Policies

c) Open and Standards based

d) Ease of Management

Secure By Default

I described "secure by default" in one of my earlier blog posts. This is a key design principle that drives the security architecture for Fusion Apps. Given that there are more than 100+ modules in Fusion Apps and more than 2000+ Web Services and Web Service Clients - as more and more modules and web services are deployed - the ability to have security by default is a key consideration.

Why do we need "secure by default"?

In in Fusion Applications we have products like ERP, HCM, etc that provide mission-critical capabilities to many organizations. Protecting data and business transactions is critical to reducing security risk;

How does Fusion Apps address "secure by default"?

Fusion Applications leverage the Global Policy Attachments (GPA) feature in OWSM to address this design goal. In addition, there are certain Web Services (Web Service Clients) in Fusion Apps that integrate with Partner systems - in this case the security requirements are different and hence LPA is used to secure these Web Services and Web Service Clients at Design Time in JDeveloper.

Externalize Security  from Applications & Declarative Policy based Security

Fusion Applications provide a lot of functionality - however we seed that:

a) Companies - extend Fusion Applications by building their own applications and integrating their applications with Fusion Applications.

b) The security requirements of Applications change over a period of time - these can be due to regulatory needs, integration needs, etc

Building security into the applications layer makes it brittle when the security requirements change, thus rather than building security into the applications layer - it is built into the Middleware layer and externalized from the Applications layer. This enables new applications that customer's may build to extend Fusion Apps to leverage the same capabilities. In addition, if the security requirements change, declarative policy based security allows one to make changes without having to change any code either in the Middleware layer or in the applications layer.

How does Fusion Apps address this design goal?

Fusion Apps leverages OWSM. OWSM provides a declarative policy based approach to addressing Web Services Security and allows one to externalize the security from Applications.

Open and Standards based

As mentioned earlier Fusion Applications expose a lot of functionality as Web Services. Many of the modules of Fusion Applications integrate with other modules via standards based Web Service interfaces. The rationale for this architecture is multi-fold:

a) Exposing functionality as Web Service interfaces - enables customer's to integrate their custom applications with Fusion Applications via Standards based interfaces.

b) Using Web Service interfaces to connect between modules enables us to build a more modular, less decoupled system and leverage the advantages of a SOA based architecture.

c) Exposing functionality as Web Service interfaces - makes it easier to deploy Fusion Apps in mixed topologies (some modules maybe on-premise and some maybe on-cloud) and still be able to integrate b/w the

d) Exposing functionality as Web Service interfaces - makes it easier to integrate/interoperate with Partner systems or other Oracle Applications - ex: Siebel, Peoplesoft systems - thus allowing customer's the choice for incremental uptake of Fusion Application modules.

These Web Services are also secured via standard Web Services Security policies - thus allowing for:

a) Standards based security.

b) Standards based interoperability with Partner systems.

How does Fusion Apps address this design goal?

Fusion Apps primarily leverage SAML token based policies for identity propagation. However not all Partner systems may support SAML - thus - Fusion Apps also support - Username Token.

Ease of Management and Being Able to Modify Default Security Posture

Fusion Apps has nearly 2000+ web services and web service clients. Fusion Apps ships with a default security posture. This default security posture may not be suitable for all companies. Given the number of Web Services and Web Service clients, being able to change the security policies if the security requirements of a company or organization change - is critical. However changing the security requirements needs to be easy and cost effective.

How does Fusion Applications address this design goal?

Fusion Apps again leverage Global Policy Attachments to address this design goal.

In a future blog post - I will discuss more concrete use-cases and lessons learnt from the Fusion Apps - which I hope customer's will find useful.

Friday Sep 16, 2011

Maintaining OWSM Policy Repository - Best Practices - 11g

OWSM provides a number of WLST commands that can help in maintaining the WSM Policy Repository. This includes upgrading the repository, rebuilding the repository, etc.

These are documented in the section "Maintaining the Oracle WSM Repository" . In this post I will briefly examine when one should consider using this based on a customer interaction.

Recently an OWSM customer ran into the issue where one of the policies we ship Out of the Box disappeared from the WSM Policy Repository in the customer installation. Unfortunately - this policy was being used to secure some of the web services in the installation.

So the first question is when may this occur?

  1. Well the Out of the Box policies we ship can be deleted. So somebody may have deleted it! [Side Note: I think we need to see if we need to improve our story here in future releases]. OR
  2. Something may have failed when we initially seed the repository with the Out of the Box policies.
If it is due to (1) - My first tip - This an excellent reason to leverage the OWSM Auditing capabilities. If somebody deleted the policy, then OWSM would have audited this operation if the Oracle FMW Audit framework had been set up in the installation.

In any case how do we recover from this? There are two WLST commands that you should be aware of that might be helpful:

a) upgradeWSMPolicyRepository() - the details of how to use this command are here.

b) resetWSMPolicyRepository(false) and resetWSMPolicyRepository(true) - the details of how to use this command are here.

In this case the customer ran the resetWSMPolicyRepository(true) command. The customer got the missing Out of the Box policies back but LOST all the custom policies that they had in the repository

First the customer should have used resetWSMPolicyRepository(false) command rather than resetWSMPolicyRepository(true). There is no way to undo this operation! Hence my next tip:

ALWAYS take a backup of the repository before you run these commands! How do you take a backup? There are several ways:

  • You can take a database backup
  • You can take a backup by exporting out the contents of the WSM Policy Repository (see this section for more details)
These commands are manipulating the entire repository, since they are dealing with the entire repository - if something goes wrong - there is no time travel here! - no way to go back to the original state!!! So backup is your best friend here and is worth the time and effort!

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.

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".

Wednesday Sep 07, 2011

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.

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