Wednesday Dec 18, 2013

Newbie to SOA/OWSM

Just came across this blog post that provides a one minute overview in Q&A form that I thought would be useful for those who are new to Oracle SOA Suite and OWSM.

You can find other posts on SOA, BPM, OSB, etc as well on the blog: http://soawork.blogspot.com/

Tuesday Dec 17, 2013

How To - Videos!!

It has been quite sometime since I have posted on the blog...but I thought I would share a How To video that we have created in Oracle to make it easier to use OWSM.

Here is a link to the you tube video. The video demonstrates how to do global policy attachments for REST services (resources) using OWSM in Enterprise Manager Fusion Middleware Control!

This video supplements some of the blog entries here, here and here on the topic of Global Policy Attachments (GPA).

We hope to have more videos soon!

Happy viewing!!

Sunday Aug 11, 2013

How To - Identity Propagation for REST using OWSM - 12.1.2

This is a follow up to my previous blog post, in that post I provided step by step instructions on how to secure a REST service and client built using Jersey JAX-RS technology that ships with Weblogic.

In this post I am providing a pointer to a detailed step-by-step instructions on how to do identity propagation for REST.

I strong encourage people read up on the previous How Tos covered in the following blog posts before attempting the How to provided in this post:

https://blogs.oracle.com/owsm/entry/how_to_owsm_12_1

https://blogs.oracle.com/owsm/entry/how_to_securing_rest_services

https://blogs.oracle.com/owsm/entry/how_to_securing_rest_clients

Sunday Aug 04, 2013

How To - Securing REST clients using OWSM - 12.1.2

This is a follow up to my previous blog post, in that post I provided step by step instructions on how to secure a REST service built using Jersey JAX-RS technology that ships with Weblogic.

In this post I am providing a pointer to a detailed  step-by-step instructions for securing both REST service and REST client.

In a future post I plan to cover the steps for doing identity propagation using SAML in the context of REST services & clients.

I strong encourage people read up on the previous How Tos covered in the following blog posts before attempting the How to provided in this post:

https://blogs.oracle.com/owsm/entry/how_to_owsm_12_1

https://blogs.oracle.com/owsm/entry/how_to_securing_rest_services



Friday Jul 12, 2013

How To - Securing REST services using OWSM - 12.1.2

As I mentioned in my earlier blog post - one of the features in 12.1.2 is the support for securing and managing REST services/clients similar to SOAP web services/clients.

I have posted a how to describing the steps involved in securing REST services using OWSM 12.1.2


Thursday Jul 11, 2013

How To - OWSM 12.1.2 Installation

As I mentioned in my previous blog post FMW 12.1.2 was released today. There are a few things that are different in terms of installation for OWSM in 12.1.2 compared to 11g. So I have created a fairly detailed Install How-To with screen shots. This complements the 12.1.2 Install guide.

Note: The How To does not describe all scenarios/topologies. It is mainly intended for demo installs and to give you a quick overview of key steps.

FMW 12.1.2 released!

FMW 12.1.2 was just released! This a major release for Fusion Middleware components.

The release basically includes the following Fusion Middleware components:

  • Oracle WebLogic Server 12c (12.1.2.0.0)
  • Oracle Coherence 12c (12.1.2.0.0)
  • Oracle TopLink 12c (12.1.2.0.0)
  • Oracle Fusion Middleware Infrastructure 12c (12.1.2.0.0)
  • Oracle HTTP Server 12c (12.1.2.0.0)
  • Oracle Virtual Assembly Builder 12c (12.1.2.0.0)
  • Oracle JDeveloper 12c (12.1.2.0.0)

Note: This release includes OWSM but does not include SOA!

Here are some quick links for people to get started.

If you want to download 12.1.2 - click here

OWSM 12.1.2 documentation can be found here.

This release includes a lot of new features as described here

Here are key ones from my perspective:

REST security support for services and  clients.

This includes support for LPA and GPA in terms of policy attachment. You can do Policy Attachment in JDeveloper, EM, WLST. Monitoring, Auditing, etc.

Support for WS-SecureConversation, WS-Trust 1.3, Web Service Federation

Enhanced Kerberos, SPNEGO support including credential delegation

Support for securing SOAP over JMS

Better Key Management support via KSS

I hope to cover many of these features in more detail in the subsequent posts!

Tuesday Jun 18, 2013

REST security and Federation - 11g

In my previous blog post on REST security I talk about how one could do identity propagation. That post generated some comments around how one could do federation for REST services.

The short answer is it depends on the type of client:

a) For non-browser type of clients - you can leverage an STS for doing federation for REST similar to SOAP services.

b) For browser type of clients - you could leverage Web Federation models.

STS based REST federation:

REST security federation

In this model however you will need to create a SOAP RST/RSTR to talk to an STS. There are some recent standards where you can talk to Security services that provide equivalent functionality as STS via REST binding instead of SOAP binding (Open ID Connect, etc). [Note: These are currently not supported by Oracle.]

Sunday Jun 09, 2013

Identity Propgation for REST APIs - 11g

In a previous blog post - I described the support we added in OWSM for securing REST APIs. There have been a few questions about OWSM support for REST security and also how we can do identity propagation and SSO for REST APIs.

Before I dwell into how one can do Identity Propagation for REST APIs. It will help to identity the different type of clients that can invoke REST APIs. In my mind - the clients can be categorized into the following:

a) Server (JEE REST) Clients - these can be built using the standard REST stacks like Jersey JAX-RS/JBoss REST Easy/etc

b) Browser Clients

c) Thick Clients like Outlook

d) JSE Clients (or clients running in a non-server and non-browser environments)

e) Mobile Clients

The security requirements vary a bit based on the type of client.

JEE Clients - Server to Server communication

For Server to Server REST communication - if you want to do Identity Propagation - I recommend using SAML. OWSM supports SAML bearer tokens. OWSM currently doesn't support securing REST clients. However you can build REST clients using programmatic models and use libraries like OPSS Trust APIs or OpenSAML, etc to construct the necessary SAML tokens and inject it into the HTTP header. This is depicted in the picture below.

You can click on the picture to see a larger image or click here.

For those who have been following my blog - this picture is very analogous to how we handle things for SOAP as described in this blog post. The only difference is there is no OWSM Agent support for securing the REST Clients and so you need to use some other libraries/toolkit.

You actually have two variants for securing REST APIs invoked by Browser based Clients:

a) Use OAM only

b) Use OAM + OWSM

If the only client for your REST APIs is a browser based client, then OAM is sufficient to secure your REST APIs.

SSO for REST APIs

Identity Propagation vs. SSO

It is important to note that Identity Propagation and SSO are not equivalent - although many people use the terms interchangeably. Although the net effect of both is the same i.e the identity of the user is available to the application - there is one significant difference.

In the case of Identity Propagation - there is no concept of Login/Logout - which basically means there is no concept of Web SSO Sessions.

If you have different type of clients invoking your REST APIs and one of the types is a browser based clients, then OAM + OWSM is a better combination.


Thick Clients like Outlook, etc

If it is Microsoft technology based clients then instead of SAML you can use SPNEGO to perform Identity Propagation.

JSE Clients

Typically Identity Propagation is not a big use-case for JSE Clients - however you can follow a similar approach to JEE Clients.

Mobile Clients

I will address Mobile Clients in a future blog post.

Tuesday Apr 16, 2013

.NET interoperability, Kerberos, SPNEGO, Id Propagation - All things Microsoft! - OWSM 11g - Revisited

In a previous blog post - I briefly talked about interoperability with Microsoft and support for Kerberos, SPNEGO, NTLM, etc in OWSM. So I wanted to revisit that post and address a few aspects:

SPNEGO support

In that blog post - I mentioned that SPNEGO is something we don't support in OWSM.

In PS6 with the introduction of the support for REST security - we also added support for SPNEGO. While the key driver was REST services and securing REST services - we support SPNEGO policies for HTTP/SOAP services as well.

In fact one of things customers will notice is that many of the policies introduced for securing REST services are also supported for HTTP/SOAP web services.

SPNEGO support is documented here:

http://docs.oracle.com/cd/E28280_01/web.1111/b32511/policies.htm#CHDEJIIF

http://docs.oracle.com/cd/E28280_01/web.1111/b32511/assertions.htm#CHDBICJC

http://docs.oracle.com/cd/E28280_01/web.1111/b32511/policies.htm#CJAIEDEG

Note: OWSM still doesn't support NTLM.

Interoperability with Microsoft environments.

One of the most common questions from customers is around can we use SAML to do identity propagation b/w Microsoft and Oracle based environments and the use of ADFS as the STS for enabling SAML based identity propagation.

In PS6 - we have certified with ADFS ( in addition to the certification with Oracle STS, OpenSSO STS).

Client side Kerberos support

It appears that many people looked at the figures in the previous blog post and assume we don't support Kerberos on the client side in OSB. I just wanted to clarify that we do in fact support Kerberos policies on the client side - so for - you can do the following:


The key limitation is that you cannot use kerberos across multiple hops as I mentioned in the previous blog post. However you can definitely use Kerberos policies to secure your web services clients.

Thursday Apr 04, 2013

Identity Context support in OWSM - 11g

Here is another quick post about yet another new feature in PS6. As many of you know we have supported identity propagation for a long time. However as things have evolved - it is clear that propagating just identities is not sufficient. We need to propagate additional contextual information - this may include for ex:

a) In the Mobile world - for example this can include whether the user is using a device that is jail broken or not

b) In the Banking space - the geo-location from where an ATM debit card or credit card might be getting used by the user.

In fact Marc Boroditsky spoke about this in Oracle Open World 2012.

This sets up the need for propagating not just the identity but the entire context! In PS6 we have taken a step in this direction.

Note: There are still some limitations - SOA Suite/OSB - for example don't yet support the ability to propagate the entire identity context.

Wednesday Apr 03, 2013

OWSM Mobile Agent for ADF Mobile

Oracle released Mobile Application development framework - called Oracle ADF Mobile sometime back. More details about the Oracle ADF Mobile framework can be found here.

In order to secure the REST/SOAP communication b/w the ADF Mobile App and the backend services - OWSM team has developed an OWSM Mobile Agent.

The capabilities right now are fairly limited - especially when you consider what is supported in the Non-Mobile case! The OWSM Mobile Agent only supports Basic Auth and Basic Auth over SSL and WS-Security Username Token and WS-Security Username Token over SSL policies.

More details about the policies supported can be found here. The good news is building a Mobile client to backend REST/SOAP web service is very similar to how you do in the "Big ADF" world i.e. you use Web Service Data Controls!

Here is the revised layered Service security diagram that I discussed initially in this post:

layered service security

P.S:I didn't see an example of how to build a Mobile App that can make Web Service calls on the Oracle ADF Mobile page; if time permits - I will post some How To's on this front...

Update: Some folks pointed me to this blog post on ADF Mobile Introduction that actually covers how to build and secure web service clients. There is also an official ADF Mobile blog for more details...

Tuesday Apr 02, 2013

OSB and OWSM integration enhancements - 11g

In my previous post, I described one of the key features that we added in OWSM for PS6 was support for securing REST services. I forgot to mention that another key addition in PS6 relates to the OSB/OWSM integration. The integration has been enhanced to address some of the more common issues that were raised by customers.

Two key enhancements in this area include:

a) Support for securing OSB REST services with OWSM Policies.

Note: OSB has not certified all the REST security policies OWSM supports in PS6.

b) Support for Attachments (MTOM, SwA) and OWSM security policies

More details on what is supported in OSB in PS6 can be found here.

FMW PS6 (11.1.1.7.0) released!

Just a quick note - FMW PS6 has been released. OWSM is part of the FMW release train. As was the case with the previous FMW Patchset release - this is a feature bearing release.

The OWSM PS6 documentation describes as part of what's new section an exhaustive list of features:

The following new features and enhancements have been added to the current release of Oracle Web Services Manager:

In future blog posts I will post in more detail about some of the features - but in this blog post I wanted to highlight one particular features that I think customers are going to find very useful:

Securing REST services (a.k.a Servlet Application Security)

Customers can build REST services in one of two ways:

  • As Servlet applications without using any REST technology stack
  • Using REST stacks like Jersey JAX-RS

In PS6 - OWSM support's securing REST services built using either methodologies. So all the capabilities and power of OWSM to secure SOAP services can now be used for securing REST services.

Here is are some quick doc pointers:

http://docs.oracle.com/cd/E28280_01/web.1111/e13734/rest.htm#BHABFDGJ

http://docs.oracle.com/cd/E28280_01/web.1111/b32511/policies.htm#CHDEJIIF

Note: In this release OWSM does NOT SUPPORT securing REST clients - for example REST Clients built using the Jersey JAX-RS stack.

Friday Feb 15, 2013

Dynamic Policy Selection among alternatives - 11g - follow up

Just a couple of quick follow up points to my blog post on Dynamic Policy Selection.

First a shout out to Chris's blog post on this topic - I missed it since he blogged about it more than 2.5 years back! He is a doing a lot of creative things in that blog post. My post was more around what is supported by OWSM out of the box.

Second - a clarification - the Dynamic Policy Selection is supported only on the service side currently.

Friday Feb 08, 2013

Dynamic Policy Selection among alternatives - 11g

A few weeks back I was discussing some requirements a few teams had within Oracle and I thought it would be a good topic to address on this blog. One of the most common scenarios that customers seem to run into is the following:

Let's say you have a Web Service. The Web Service supports SAML. Now if Web Service Clients are able to support SAML you are in good shape and they can talk to your Web Services. However if a Web Service Client cannot support SAML then you have a problem. Let's assume for  a second that the Web Service Client can support Kerberos but not SAML.

This mismatch in security capabilities is a fairly common occurrence. 

Before I talk about the specific feature of Dynamic Policy Selection that is supported in OWSM - let's see what are the various ways to solve this problem:

a) Option#1: Use Oracle STS to do Token Exchange/Conversion

b) Option#2: Build SAML capability in the Web Service Client or use Web Services Security technology that supports SAML

c) Option#3: Add Kerberos support to the Web Service.

Here we have two scenarios:

Scenario#3.1: Expose two Web Service Ports one using SAML and the other using Kerberos.

Scenario#3.2: Dynamic Policy Selection on the Service

d) Option#4: Use Oracle Enterprise Gateway or Oracle Service Bus

I will describe briefly each of the options and the advantages and disadvantages of each option.

So a customer has four options. Different options have different implications on different parties.

Option#1: Use Oracle STS to do Token Exchange/Conversion

As I mentioned in a previous blog post - you can use a Oracle STS. Just to reiterate - this will look as follows:

Oracle STS - Token Exchange/Conversion

Advantages:

a) The Security story on the Web Service side is fairly simple - you can standardize on one particular token - ex: SAML that all clients need to adhere to...

Disadvantages:

a) The onus is on the Client to bridge the difference b/w what the Web Service supports and what the client supports.

b) The Client needs to have the capability to be able to talk to an STS.

Option#2: Build SAML capability in the Web Service Client or use Web Services Security technology that supports SAML

 Well this fairly self evident - if you can add the SAML support on the client - then there is not mismatch! Ex: use OWSM for example to secure your Web Service client and viola problem solved :-)

Advantages:

a) The Security story on the Web Service side is fairly simple - you can standardize on one particular token - ex: SAML that all clients need to adhere to...

b) No new components into the mix - ex: Oracle STS

Disadvantages:

a) It may not always be possible to add SAML support - depending on the technology stack being used on the Web Service Client side!

Option#3: Add Kerberos support to the Web Service

In this approach instead of client changing, the service side is modified to add Kerberos support. There are two ways to address this:

Scenario#3.1: Expose two Web Service Ports one using SAML and the other using Kerberos.

This is shown in the figure below (click for larger image).

different web service ports for different security

Advantages

a) The advantage of this approach is the clients are not impacted.

Disadvantages

a) The Web Service has to support multiple web services - one for each security token or security requirement.

b) More overhead in terms of maintaining, testing.

c) If a technology stack does not support adding Web Service Ports dynamically  - then the application has to go back to the Development and so the administrator cannot address this requirement.

d) Assumes the Web Service/Web Service Security stack on the service side can support Kerberos.

Scenario#3.2: Dynamic Policy Selection on the Service

OWSM - Dynamic Policy Selection

In this model the Web Service is configured with a policy that basically supports both SAML "OR" Kerberos [1]. When the Web Service Client invokes the Web Service - based on the contents of the message the appropriate option is selected. So if the Desktop application sends Kerberos Token - then the Kerberos Option in the policy is executed. If the On Premise App sends the SAML token in the SOAP message the SAML Option in the policy is executed.

High level Description:

So the way to achieve this in OWSM is by constructing an ExactlyOne Policy which contains two assertions - one is a SAML authentication assertion and the other is the Kerberos Authentication assertion.

<ExactlyOne>

<SAML Authentication>

<Kerberos Authentication>

</Kerberos>

You can author such a policy using Enterprise Manager Fusion Middleware Control as described in the OWSM documentation here.

Advantages:

a) No changes to the Web Service/Application itself. So a customer does not have to go back to the Development teams to add new Web Service Port every time the security requirement changes.

b) Administrator can make the changes by creating new combinations based on requirements

c) Web Service Clients  are not impacted

Disadvantages:

a) The customer hosting the Web Service has to still test two security models! So there is still some testing, maintenance overhead.

b) Assumes the Web Service/Web Service Security stack on the service side can support Kerberos and Dynamic Policy Selection.

Notes:

[1] For purposes of simplicity - I use the terminology "OR" above but "OR" operator and ExactlyOne are not identical in semantics.

[2] OWSM currently ships a few policies Out of the box (OOTB) that have this capability. Ex: See here and here. This section in the OWSM doc - describes the client policy and service policy compatibility which provides you a good overview.

Option#4: Use Oracle Enterprise Gateway or Oracle Service Bus

In this option OEG or OSB will act as an intermediary and do the token conversion - potentially in conjunction with an STS.

OEG as an intermediary for token mediation

Advantages

a) No impact for Client or the actual backend Web Service. The onus shifts to the intermediary in this case OEG or OSB.

b) If the Client cannot be modified or the backend Web Service cannot be modified - this is pretty much becomes the only option!

Disadvantages

a) You need a new component - OSB or OEG in the mix

b) The intermediary has to easily support Scenario#3.1 or Scenario#3.2 itself - otherwise we have just shifted the problem to a different layer!

 In this blog post - I took a concrete example - i.e. Kerberos and SAML - but the concept applies in general to any mismatch in security capabilities that customers may find between a Web Service Client and Web Service.

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.

Monday Dec 03, 2012

OWSM Permission based Authorization in SOA - 11g

Just came across a nice blog post on how to do authorization in SOA using the OWSM permission based authorization policy.

One big caveat is in order: SOA does not support the concept of "Application Roles". So the grant is done to the enterprise role (i.e. ldap group). If I get sometime I will post more about the differences b/w doing grants for Application Roles vs. Enterprise Roles.

Update: So I added a big caveat while linking to the above blog post but did not add any explanation. This had folks confused - since the blog post explicitly talks about Application Roles!

Well if you look at the blog post - it talks about Application Roles in the "soa-infra" Application stripe. The "soa-infra" Application Stripe is the stripe of the SOA Suite container.

I would NOT recommend using the SOA Suite container's Application Stripe for SOA Composite Applications for a couple of reasons:

a) The lifecycle aspects become horrendously complicated when you mix Application Roles applicable for SOA Composite applications that a customer builds in the same stripe that is used by the SOA container. For ex: In a future release the SOA container might decide to use a different stripe for it's application roles - if a customer is using this stripe then all the authorizations for SOA Composite applications would start failing when they upgrade to the new release. You can potentially also cause the SOA container to stop working - if you delete or modify the Application Roles that it ships. Fundamentally - the soa-infra stripe is owned by the SOA container for it's working and customers should not be using it for their own composite apps.

The closest analogy to what is being done in the blog post would be a comparison b/w WLS Application Server and J2EE Apps. I would not recommend mixing the security artifacts that ship with the Application Server for it's own internal working with the security artifacts that is required for a customer developed J2EE application. Patching, Upgrade, T2P, etc are all very different.

b) The other reason of course is this is no really scalable. You can have hundreds of composite applications. If you use a single application stripe "soa-infra" - then there is impact when you move let's say one composite application from Test to Production. How do you move the corresponding application roles that are relevant for only that particular composite app. In addition there are performance implications - if you have hundreds of composite applications and each composite application defines it's own Application Role - then you end up defining hundreds of Application Roles.

So in order to avoid getting into the above type of issues - I recommend customers stick to enterprise roles (ldap groups).

Note: This recommendation to avoid Application Roles and use Enterprise Roles (Ldap Groups) is only for SOA composite applications. For JEE Applications - using Application Roles is beneficial and the lifecycle issues that I describe above don't exist.

In a future blog post - I will describe the advantage of Application Roles.

Wednesday Nov 14, 2012

Cloud Integration Using Oracle SOA Suite - 11g

There is a very good blog post by Rajesh Raheja on how you can use Oracle SOA Suite for Cloud Integration. He also has a link to white paper on his blog as well.

In a future blog post I will describe some of the security challenges and how to address them using OWSM for Web Services.

OWSM HowTo for starters/newbies - 11g

Not much blogging the past few months as I have been a bit busy with my day job!

In the meantime I thought I would share a blog post from Vinay on OWSM that people may find useful. Happy reading!

Thursday Aug 16, 2012

Interop with Microsoft - OWSM 11g

As they say when it rains it pours! So it has been with my blog posts:-) Anyway this is another short post - I was talking about all things Microsoft and lucky me - I found this article dealing with Microsoft silverlight and OSB and OWSM and I thought I would share a link!

Custom assertion/policy examples in the wild - OWSM 11g

Since recently i have been talking about custom assertions and policies quite a bit (here, here and here)- I thought I would share some more concrete samples (and looks like rather than me having to build it on my own - i can just point to others who have done this already!!)

So here is a quick pointer:

http://www.cohesion.com.au/articles/owsm-custom-policy-partI

http://www.cohesion.com.au/articles/owsm-custom-policy-partII

Happy coding!

Wednesday Aug 15, 2012

OWSM Gateway vs. OEG - OWSM 11g

I came across this blog post http://www.narendranaidu.com/2011/11/oracle-web-service-manager-vs-oracle.html about confusion b/w OWSM Gateway and OEG and I thought I would post a quick clarification.

I have already described earlier about OWSM vs. OEG here and Oracle's vision for layered security here. However I didn't address OWSM Gateway vs. OEG!

As many of you know in OWSM 11g - there is no OWSM Gateway - we have only OWSM Agents. The OWSM Gateway Narendra is talking about is referring to the OWSM 10g Gateway. OEG is the 11g successor to the OWSM 10g Gateway.

Hope that clarifies any confusion!

Update#1: Here is a document that describes how to migrate from OWSM 10g Gateway to OES OEG 11g.

.NET interoperability, Kerberos, SPNEGO, Id Propagation - All things Microsoft! - OWSM 11g

One of the most common questions I run into relates to .NET/WCF interoperability with OWSM.

First - officially OWSM certifies a few interop scenarios with .NET. These are covered in the OWSM Interop guide

They key scenarios certified for interop involve Username Token, X509 Token and Kerberos Token via the WS-Security Kerberos Token Profile.

The next question I hear is around how do we do Identity Propagation when we have .NET.

Scenario#1: Identity Propagation b/w WCF Client and OWSM/Fusion Middleware using Kerberos and SAML with OSB as active intermediary


Note: Instead of OSB you can use SOA Suite as well and that would work as well.

Scenario#2: Identity Propagation b/w WCF Client and OWSM/Fusion Middleware using Kerberos with OSB as passive intermediary


Note: The passive intermediary model applies for OSB (or OEG) but not for SOA, since SOA does not support passive intermediary model.

Scenario#3: Kerbeors based Multi-hop Identity Propagation b/w WCF Client & OWSM/Fusion Middleware and OSB as active intermediary


In this scenario - customer's want to use Kerberos for Identity propagation across multiple hops. This is currently not supported.

Scenario#4: Kerbeors based Multi-hop Identity Propagation b/w WCF Client & WCF Service and OSB as active intermediary


In both scenario#3 and scenario#4 in order to use Kerberos for multi-hop end-user identity propagation, you need to support either the end user TGT or the S4U Extension. Neither of these are currently supported in OWSM.

Scenario#5: Using SAML for end-to-end identity propagation.


So another way to do end-to-end identity propagation that will work with OSB or SOA Suite is to SAML. WCF/.NET supports talking to an STS to exchange a kerberos token for a SAML token and then SAML can be used across multiple hops.

Note:

1) While this scenario has not been certified explicitly by OWSM, it should work since OWSM supports WS-Trust.

2) In the diagram I use Oracle STS but any STS can be used as long as that STS supports exchanging a Kerberos token for SAML token.

I have not listed all the possible scenarios here - but hopefully this provides a sense of what is possible today and what is not possible.

SPNEGO

I also see a lot of questions around SPNEGO support. OWSM currently does not support SPNEGO. You can read all about SPNEGO here

One could build a custom assertion to add SPENGO support in OWSM. However you need to keep in mind that with SPNEGO unlike the WS-Security Kerberos Token Profile, the Kerberos Token is actually in the HTTP reader rather than in the SOAP WS-Security header.

So the Kerberos token is wrapped in the HTTP header under the auth-scheme called "Negotiate". The WWW-Authenticate and Authorization headers are used to communicate the SPNEGO token between client and service. This is explained in the steps below:

  1. The client requests access to a protected document on the server without any Authorization Header.
  2. Since there is no Authorization Header in the request, server responds with 401 Unauthorized and WWW-Authenticate: Negotiate.
  3. The client will use the user credentials to obtain the token and then send it to the server in the Authorization header of the new request.For e.g.,   Authorization: Negotiate a87421000000492aa874209
  4. The server will decode this token by passing it to the acceptSecContext() GSSAPI. If the context is not complete (in the case of Mutual Authentication) the server will respond with a 401 status code with a WWW-Authenticate header containing the GSS-API data. For e.g., WWW-Authentiate: Negotiate 74900a2a...
  5. The client will decode this data and send new data back to the server. This cycle will continue until the security context is established.

Since there is request/challenge model - typically the SPNEGO security model is harder to accomplish in intermediaries like OSB/OEG - if they are acting as "passive intermediaries". An active intermediary model maybe more appropriate.

For OSB itself there may be an alternate model to supporting SPNEGO. There is an excellent post from the A-Team on OSB & SPNEGO (Note: It deals with OSB 10gR3). Here is another post that covers SPNEGO

NTLM

The next question that often comes up is around NTLML support.OWSM currently does not support NTLM. As this wikipedia entry on SPENGO describes - NTLM is a variant.As you can see Microsoft no longer recommends NTLM. However if customers really want to support NTLM - they can build a custom policy.

Tuesday Aug 14, 2012

Custom Assertion in OWSM - OES, OSDT (Oracle Security Developer Toolkit) & OWSM - 11g

Another quick note on OES, OSDT and OWSM. As I have mentioned in a previous post here, OWSM provides an Extensibility Guide that allows customers to build custom policies and custom assertions. 

So the question is: When should one have to build a custom assertion in OWSM 11g?

The short answer is when something is not supported in OWSM directly.

Here are a few scenarios:

a) If you want to build say OES integration for fine grained authorization based on content. OWSM in 11gR1 as of the writing of this post does not provide OES integration, but you can build an OES integration using the custom assertion support in OWSM 11g.

Here is an example that illustrates OWSM-OES integration using the custom assertion support in OWSM 11g. There is another example in the OWSM Extensibility Guide.

b) Another example would be - if you want to build OAuth support to secure your services with OAuth. OWSM 11g currently does not have OAuth support - but if you wanted to secure your services with OAuth - you could build a custom assertion to do the same.

c) Or you want to use a particular canoncalization method (ex:. The OOTB policies, assertion templates do not provide the flexibility of implementing your own canoncalization method) or want to use particular security transformations.

d) You wanted Liberty support in OWSM, etc.

In the rest of the post I will focus on building custom assertions that require a particular type of signing or encryption.

Custom Assertion, Signing, Encryption

Now one of things one has to worry about when building a custom assertion that deals with signing, encryption, etc is what XML security toolkit to use.

As you will notice - the OWSM Extensibility Guide does NOT provide any APIs that you can use for signing, encryption, etc.

The good news is you can use OSDT (Oracle Security Developer Toolkit) that actually exposes a lot of APIs to perform various XML security operations including signing, encryption, decryption, signature validation, etc.

Here are some doc pointers to OSDT:

http://docs.oracle.com/cd/E23943_01/security.1111/e10037/toc.htm

Here are some OSDT javadocs:

Web Services Security: http://docs.oracle.com/cd/E23943_01/apirefs.1111/e10678/toc.htm

XML Security: http://docs.oracle.com/cd/E23943_01/apirefs.1111/e10680/toc.htm

JCE Crypto APIs: http://docs.oracle.com/cd/E23943_01/apirefs.1111/e10697/toc.htm

SAML related APIs: http://docs.oracle.com/cd/E23943_01/apirefs.1111/e10675/toc.htm

http://docs.oracle.com/cd/E23943_01/apirefs.1111/e10676/toc.htm

Liberty APIs :http://docs.oracle.com/cd/E23943_01/apirefs.1111/e10670/toc.htm

http://docs.oracle.com/cd/E23943_01/apirefs.1111/e10671/toc.htm

Note: The combination of OSDT and OWSM Extensibility Guide provides you a really powerful APIs and toolkits to build various types of security policies that deal with either XML security or Web Services (SOAP) security.

WARNING: You really need to know what you are doing when using these APIs. These are fairly low level APIs and the docs expect the developer using these APIs to be extremely knowledgeable about security technologies and concepts and how to use the various low level building blocks.

Hopefully this provides some guidance on how one can use OWSM custom assertion and OSDT to build various types of policies in OWSM.

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