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.

Sunday Jul 29, 2012

OPSS vs. OWSM 11g

Have been a bit busy and so blogging has been slow - but I recently came across this blog entry and I thought it would be worth clarifying about the relationship between OPSS and OWSM.

OPSS - Oracle Platform Security Services - provides a security framework and acts as the underlying security layer that addresses both FMW security requirements as well as the base for all the Identity and Access Management products.

Details can be found here.

There is a nice white paper accompanying the recent IDM 11gR2 release - that describes the foundational nature of OPSS. (Yet more material on IDM 11gR2 can be found here.)

The primary security services provided by OPSS include:

a) Authentication Services via Login Modules

b) Keystore Service

c) Credential Store Service - used for storing secrets like passwords (credentials).

d) Audit service

e) Authorization

OWSM is primarily focused on security for Web Services and provides a policy based security model. OWSM implements the various WS-* standards and  leverages OPSS authentication service, Keystore service, Audit service, credential store service, authorization service, etc.

Tuesday Jun 12, 2012

Identity Propagation for Web Service - 11g

I came across this post from Beimond on how to do identity propagation using OWSM.As I have mentioned in the past here, here and here - Beimond has a number of excellent posts on OWSM. However I found one part of his comment puzzling. I quote:

"OWSM allows you to pass on the identity of the authenticated user to your OWSM protected web service ( thanks to OPSS ), this username can then be used by your service. This will work on one or between different WebLogic domains. Off course when you don't want to use OWSM you can always use Oracle Access Manager OAM which can do the same." The sentence in red highlights the issue i find puzzling.

In fact I just discussed this particular topic recently here.

So let me try and clarify on a few points:

a) OAM is used for Web SSO.

b) OWSM is used for securing Web Services. You cannot do identity propagation using OAM for Web Services.

c) You use SAML to do identity propagation across Web Services. OAM also supports SAML - but that is the browser profile of SAML relevant in the context of Web SSO and is not related to the SAML Token Profile defined as part of the WS-Security spec.


Monday Jun 11, 2012

Permission based Authorization vs. Role based Authorization - Best Practices - 11g

In previous blog posts here and here I have alluded to the support in OWSM for Permission based authorization and Role based authorization support. Recently I was having a conversation with an internal team in Oracle looking to use OWSM for their Web Services security needs and one of the topics was around - When to use permission based authorization vs. role based authorization?

As in most scenarios the answer is it depends! There are trade-offs involved in using the two approaches and you need to understand the trade-offs and you need to understand which trade-offs are better for your scenario.

Role based Authorization:

  • Simple to use. Just create a new custom OWSM policy and specify the role in the policy (using EM Fusion Middleware Control).
  • Inconsistent if you have multiple type of resources in an application (ex: EJBs, Web Apps, Web Services) - ex: the model for securing EJBs with roles or the model for securing Web App roles - is inconsistent.
  • Since the model is inconsistent, tooling is also fairly inconsistent.
  • Achieving this use-case using JDeveloper is slightly complex - since JDeveloper does not directly support creating OWSM custom policies.

Permission based Authorization:

  • More complex. You need to attach both an OWSM policy and create OPSS Permission authorization policies. (Note: OWSM leverages OPSS Permission based Authorization support).
  • More appropriate if you have multiple type of resources in an application (ex: EJBs, Web Apps, Web Services) and want a consistent authorization model.
  • Consistent Tooling for managing authorization across different resources (ex: EM Fusion Middleware Control).
  • Better Lifecycle support in terms of T2P, etc.
  • Achieving this use-case using JDeveloper is slightly complex - since JDeveloper does not directly support creating/editing OPSS Permission based authorization policies.

Thursday May 31, 2012

Identity Propagation across Web and Web Service - 11g

I was on a customer call recently and this topic came up. In fact since this topic seems to come up fairly frequently - I thought I would describe the recommended model for doing SSO for Web Apps and then doing Identity Propagation across the Back end web services.

The Image below shows a typical flow:

Here is a more detailed drill down of what happens at each step of the flow (the number in red in the diagram maps to the description below of the behind the scenes processing that happens in the stack).

[1] The Web App is protected with OAM and so the typical SSO scenario is applicable. The Web App URL is protected in OAM. The Web Gate intercepts the request from the Browser to the Web App - if there is an OAM (SSO) token - then the Web Gate validates the OAM token. If there is no SSO token - then the user is directed to the login page - user enters credentials, user is authenticated and OAM token is created for that browser session.

[2] Once the Web Gate validates the OAM token - the token is propagated to the WLS Server where the Web App is running. You need to ensure that you have configured the OAM Identity Asserter in the Weblogic domain. If the OAM Identity Asserter is configured, this will end up creating a JAAS Subject.

Details can be found at:

http://docs.oracle.com/cd/E23943_01/doc.1111/e15478/webgate.htm#CACIAEDJ

[3] The Web Service client (in the Web App) is secured with one of the OWSM SAML Client Policies. If secured in this fashion, the OWSM Agent creates a SAML Token from the JAAS Subject (created in [2] by the OAM Identity Asserter) and injects it into the SOAP message.

Steps for securing a JEE JAX-WS Proxy Client using OWSM Policies are documented at:

http://docs.oracle.com/cd/E23943_01/web.1111/b32511/attaching.htm#BABBHHHC

Note: As shown in the diagram - instead of building a JEE Web App - you can also use WebCenter and build portlets. If you are using WebCenter then you can follow the same architecture. Only the steps for securing WebCenter Portlets with OWSM is different.

http://docs.oracle.com/cd/E23943_01/webcenter.1111/e12405/wcadm_security_wss.htm#CIHEBAHB

[4] The SOA Composite App is secured with OWSM SAML Service policy. OWSM Agent intercepts the incoming SOAP request and validates the SAML token and creates a JAAS Subject.

[5] When the SOA Composite App tries to invoke the OSB Proxy Service, the SOA Composite App "Reference" is secured with OWSM SAML Client Policy. Here again OWSM Agent will create a new SAML Token from the JAAS Subject created in [4] by the OWSM Agent and inject it into the SOAP message.

Steps for securing SOA Composite Apps (Service, Reference, Component) are documented at:

http://docs.oracle.com/cd/E23943_01/web.1111/b32511/attaching.htm#CEGDGIHD

[6] When the request reaches the OSB Proxy Service, the Proxy Service is again secured with the OWSM SAML Token Service Policy. So the same steps are performed as in [4]. The end result is a JAAS Subject.

[7] When OSB needs to invoke the Business App Web Service, it goes through the OSB Business Service. The OSB Business Service is secured with OWSM SAML Client Policy and step [5] is repeated.

Steps for securing OSB Proxy Service and OSB Business Services are document at:

http://docs.oracle.com/cd/E23943_01/admin.1111/e15867/proxy_services.htm#OSBAG1097

[8] Finally when the message reaches the Business App Web Service, this service is protected by OWSM SAML Service policy and step [4] is repeated by the OWSM Agent.

Steps for securing Weblogic Web Services, ADF Web Services, etc are documented at:

http://docs.oracle.com/cd/E23943_01/web.1111/b32511/attaching.htm#CEGCJDIF

In the above description for purposes of brevity - I have not described which OWSM SAML policies one should use; OWSM ships with a number of SAML policies, I briefly described some of the trade-offs involved with the various SAML policies here.

The diagram above and the accompanying description of what is happening in each step of the flow - assumes you are using "SAML SV" or SAML Bearer" based policies without an STS.

Thursday May 24, 2012

SSL vs. Non-SSL OWSM Policies - 11g

I was having a conversation with a colleague and we were discussing about OWSM SSL policies vs. Non-SSL policies. For the uninitiated - here is the OWSM documentation that talks about the pre-defined OWSM policies. 

So I thought I would share that conversation with this quick post...

As you can see from the list OWSM ships a bunch of policies that require SSL. The discussion we were having was what is the benefit of using OWSM SSL policies vs. using OWSM Non-SSL Policies over SSL.

The first thing to note about OWSM SSL Policies (ex:oracle/wss_username_token_over_ssl_service_policy) is they don't automatically enable SSL!

You still need to enable SSL at the Application Server level ex: in WLS or WAS.

The second thing to note is that OWSM Non-SSL Policies can be used over SSL.

So if the OWSM SSL Policies don't enable SSL automatically why use them?

The OWSM SSL Policies enable three things at a very high level:

a) The SSL Policies ensure that SSL is actually enabled. If SSL is not enabled the requests will fail. Certain SSL Policies require two-way SSL (where as others required one-way SSL), for the SSL policies that require two-way SSL - they check to ensure two-way SSL is enabled - otherwise the requests will fail.

b) WS-SecurityPolicy standards compliance. WS-SecurityPolicy defines standards in terms of what exists in the WSDL when you are using SSL. The OWSM SSL Policies ensure that what is "advertized" in the WSDL is WS-SecurityPolicy compliant. This will ensure clients that understand WS-SecurityPolicy can comply with what is described in the WSDL. (ex: Microsoft)

c) In some cases the SSL Policies sign the SAML token, etc. So for ex: if you have configured oracle/wss10_saml_token_service_policy over SSL it is not equivalent to using oracle/wss_saml_token_over_ssl_service_policy

For these reasons if you are using SSL as Transport layer security - I recommend using the OWSM SSL policies rather than using the Non-SSL policies over SSL.

Wednesday May 23, 2012

WLS Custom Authenticator, OPSS Custom Identity Store Service, OWSM Custom Assertion - custom everything!! - 11g

Between WLS, OWSM, OPSS - Oracle supports a lot of flexibility in building custom security. However sometimes customer's maybe overwhelmed and find all this very confusing. This post provides a brief overview of the purpose of each and when to use them.

WLS Custom Authenticator (or Custom Authentication Provider)

Weblogic provides the ability to build Custom Authentication Providers. WLS documentation describing how to build "Security Providers" is described here.

When should you build it?

Typically you build a custom authentication provider - when your users are stored in "custom" repository.

Ex#1: Let's say you have users in a mainframe repository and you cannot use the OOTB Ldap or SQL Authentication Providers.

Ex#2: The users are stored in DB but the schema is custom and so the OOTB SQL Authentication Provider does not work.

We will use the terminology "Identity Store" to identify a repository where users are stored.

OPSS Custom Identity Store Service

OPSS supports the ability to configure the "Identity Store" service as part of a weblogic domain via the "jps-config.xml". OPSS OOTB currently does not support Oracle DB as an "Identity Store". If you have users in a DB or mainframe system - you may want to build a custom identity store service.

 

When should you build it?

The OPSS Identity Store service can be used to retrieve user profile information. Ex: If you want to retrieve the email of user in the "Identity Store".

OPSS provides what is called User/Role APIs and these APIs ultimately need to talk to the "Identity Store" to retrieve user profile information.

You can find details about the OPSS Identity Store service here.

OWSM Custom Assertion

I have briefly described about OWSM Custom Assertion/Policy support in this blog post.

When should you build it?

There are many scenarios where you may want to build a custom assertion.

Ex#1: Let's say you need to support a proprietary token (ex: CA SiteMinder Token) in your Web Services for authentication.

Ex#2: You want to support say a JWT token for your Web Services for authentication.

Hopefully this clarifies some of the confusion.

Note: There are a lot of nuances to each of the scenarios described in this post. I have tried to keep the post at a high level and gloss over many of nuances for purposes of brevity.

Monday Apr 16, 2012

Oracle BPM and OWSM - 11g

The Oracle BPM team has an article on how to use OWSM with Oracle BPM. The article covers specifically how to use OWSM SAML based identity switching policy (I briefly talked about the SAML identity switching feature in OWSM in the blog post).

Hope people find it useful! (There is a typo in the title it should say BPM 11g: Configuring SAML Web Service Clients for Identity Switching without Message Protection).

Thursday Apr 12, 2012

OEG integration with OSB/OWSM - 11g

This is a follow up to my post on Oracle's layered SOA Security vision. There is a very nice article from Fabio Mazanatti & co describing How to integrate OEG with OSB/OWSM

Check it out!

Friday Mar 30, 2012

OSB Security using OWSM - 11g

Here is a very nice video showing how OWSM can be used to secure OSB from Oracle.

Wednesday Mar 21, 2012

OWSM vs. OEG - When to use which component - 11g

A lot of people both internal to Oracle and customers keep asking about when should OWSM be used vs. OEG. Sometime back I posted Oracle's vision for layered SOA security

Here is a quick summary:

Use OWSM in Green Zone

Use OEG in Red Zone (DMZ)

If you need end-to-end security in which case they will want both OWSM and OEG. This is the topology I would recommend for most customers.

If you need only Green Zone security - then use OWSM in conjunction with Oracle FMW products like SOA Suite, OSB, ADF, WLS, BI, etc both on the Client Side and Service Side (assuming you are using FMW technologies for both Clients and Services).

If you need only Red Zone security - then use OEG on the Service Side. You can use OWSM for the Client Side if you are using FMW to build your clients.

Sunday Mar 18, 2012

How To - Securing a JAX-WS with OWSM Message Protection Policy in JDeveloper - 11g

As promised in this post, here is a How-To that describes how to secure a simple HelloWorld JAX-WS with OWSM message protection policy and test it with SOAP UI.

The How-To reuses the picture I posted earlier about the relationship and interplay b/w Keystore, Credential store, jps-config.xml ,etc.

One of the other more frequent requests I hear from folks within Oracle and customers is how to test OWSM with SOAP UI. SOAP UI in general works very well as testing tool for web services secure with wss10 policies.

Saturday Mar 17, 2012

Podcast on SOA Governance and OWSM - 11g

Anand Kothari the Product Manager for OWSM has a great podcast on SOA Governance and how OWSM, OEG help the SOA Governance story.


Keystore and Credential Store interplay in OWSM - 11g

One of the most common problems faced by customer's is the use of the keystore and it's interplay with the credential store.Here is a picture that describes these relationships.(Click on the picture for a larger image). The picture makes some assumptions in describing the relationship. Some of assumptions are:

a) the key used for signing and encryption are the same.

b) A keystore can have multiple keys and each key can have it's own alias. In the picture I show only a single key with alias "orakey".

c) The keystore being described here is a JKS keystore. Things can vary slightly for other type of keystores.

I hope to have a detailed How To that provides the larger picture and then shows these relationships in that context and this picture was created in the context of that How-To. However I think people will find this picture useful on a standalone basis as well. The <serviceInstance> is the entry you will find in jps-config.xml


Keystore, Credential Store, jps-config.xml

Friday Mar 16, 2012

OWSM Policy Repository in JDeveloper - Tips & Tricks - 11g

In this blog post I discussed about the OWSM Policy Repository that is embedded in JDeveloper. However some times people may run into issues with the embedded repository. Here is screen snapshot that shows the error you may run into (click on the image for larger image):

If you run into "java.lang.IllegalArgumentException: WSM-04694 : An invalid directory was provided to connect to a file-base MDS repository." this caused due to spaces in the folder name. Here is a quick way to workaround this issue by running "Jdeveloper.exe - su".

Hope people find this useful!

Wednesday Mar 14, 2012

How To - SOA Component level Role based Authorization using OWSM - 11g

Here is another How-To that provides detailed instructions for How To perform role based authorization for a SOA Composite app.

These are fairly large documents since I am providing a detailed step by step instructions. If you are familiar with some or all of the technologies - you can jump around the How-To to the relevant sections.

Note:

In many cases the How-To's may have typos and other mistakes - please let me know if you see any issues in the How-To and I will try and fix them.

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.

Friday Feb 24, 2012

Constraint based Global Policy Attachments (CGPA) - 11gR1

There are quite a few new features that were delivered as part of OWSM 11gR1 PS5 (11.1.1.6.0). One of the new features that was delivered is the ability define Constraint based Global Policy Attachments (or sometimes referred to as Conditional Global Policy Attachments). 

In this post - i will provide a brief illustration of the use-case that motivated addition of that feature.

Consider you have a Web Service. In many cases Web Services are exposed both within the internal network of an organization and/or in many cases the same Web Services are exposed outside the organization so that clients such as partners, etc can access these Web Services. So we can categorize Web Services into three categories:
  • External facing Web Services i.e. web services accessed by external web service clients.
  • Internal facing Web Services i.e. web services accessed by internal web service clients.
  • Mixed Web Services i.e. web services that are accessed by both internal and external Web Service Clients.

In many cases customers want to have different levels of security for web services accessed by internal web service clients, compared to those web services that are accessed by external web service clients (ex: Partners or clients accessing services hosted on a public or private cloud).

Web Service Type
Security Level
 Internal Web Services
 Low
 External Web Services
 High
 Mixed Web Services
 ?

Here is a pictorial representation of the use-case.


Typically the only way to solve this to use High level security for Mixed Web Services - this results in Internal Web Services also using High level of security. The Conditional Global Policy Attachments feature is designed to address this scenario. It allows Internal access to continue to use Low level security, while External access can continue to use High level security.

Another relevant aspect that customer's typically run into is sometimes Web Services that are flagged as Internal may then need to be exposed Externally and this transition requires changing the Security level. Conditional Global Policy Attachments obviates the need for handling these type of scenarios.

OWSM 11gR1 PS5 (11.1.1.6.0) released!!!

Haven't had a chance to blog in quite sometime - but this is a quick post to note that - FMW 11gR1 PS5 was released a few days back and that includes OWSM 11gR1 PS5.

The OWSM documentation lists what is new in 11gR1 PS5 at:

http://docs.oracle.com/cd/E23943_01/web.1111/b32511/whatsnew.htm#CJAJEBDH

I hope to blog more on some of the new features in 11gR1 PS5 and the use-cases driving the support for these features.

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.

Monday Nov 28, 2011

Running OWSM WLST commands - 11g

It has been sometime since I posted some materials. I hope to have more tips, best practices - but here is a quick thing that people seem to trip up on..."How to Run OWSM related WLST commands"

The most common issue people seem to run into is trying to run the OWSM WLST commands from the wrong location. You need to run the WLST commands from "oracle_common/common/bin/wlst.sh" (ex: /home/Oracle/Middleware/oracle_common/common/bin/wlst.sh)

This is documented in the OWSM doc (Security And Administrator's Guide) under the section "Accessing the Web Services Custom WLST Commands".

Note: This location is different from the location from where you run the SOA WLST commands.

If you try to run the OWSM WLST command from the wrong location - you will see errors like the following: "The MBean ,@ oracle.wsm:*,name=WSMDocumentManager,type=Repository was not found"

Tuesday Oct 11, 2011

When to use OWSM? - 11g

I came across this interesting blog post from Gaurav Sharma that describes why he was initially skeptical of using OWSM to secure web services that are hosted in the intranet and what changed his mind.

What were the things that I found interesting?

  1. Gaurav focuses mainly on securing the message in transit
  2. His main concern even when discussing about securing messages when they are in transit is focused on apps handling sensitive information like financial information.
  3. If you are really a security fanatic - you will pick up on a third interesting tidbit - related to #2 - is that his main concern is around ensuring components outside the intranet are not in a position to access the sensitive information.
  4. Discussion about the performance implications

I think there is a broader list of security aspects that you need to consider - many of these were discussed a long time back in an article I co-authored and is available here. I have re-enumerted them here for convenience.

  • Authentication  (AuthN for short)
  • Authorization (AuthZ for short)
  • Spoofing
  • Tampering
  • Repudiation
  • Information Disclosure
  • Denial of Service
  • Replay attacks
  • Virus attacks and Intrusion Detection

The list of security issues is pretty comprehensive for the most part - but I will elaborate on two - Authentication, Authorization here:

If you need AuthN - there are some additional considerations that need to be considered in this space:

  • Does your Web Service need to support Identity propagation?.
  • Does your  Web Service need to support Brokered AuthN?
  • Does your Web Service need to support Federated Identity scenarios?

If you need AuthZ - there are few additional considerations as it relates to AuthZ:

  • Does your Web Service need to support Role based AuthZ?
  • Does your Web Service need to support Permission based AuthZ?
  • Does your Web Service need to support Fine grained AuthZ?
  • Does your Web Service need to support Context aware AuthZ and in general Context-aware Security? (Here is an article on the need for Context aware security)

Now not all of these security aspects are not necessarily relevant; if you have web services that are exposed in the intranet or these are departmental web services.

However you do need to consider the surface area of exposure for your web services - especially with what is being termed as the "Consumerization of IT" and the security challenges this presents.

Even assuming your departmental web services are do no have a large exposure and are accessible only via the corporate intranet - they typically require authentication and authorization. In addition auditing is also typically required to address compliance needs mandated by various regulatory requirements.

It is worth noting that OWSM does not necessarily address all the security issues - especially relating to Virus attacks, Throttling of requests, Intrusion Detection, etc.

Oracle's SOA Security Strategy is shown in the below embedded picture.

SOA Security Strategy

Here is a link to this image.  Hopefully this post helps people in considering the various security challenges and how the different Oracle products address these security challenges.

Updated: Corrected typos.

Sunday Oct 09, 2011

SAML support in OWSM - Best Practices - Part#1 - 11g

As mentioned in my past posts Ediwn Beimond has a great post on SAML support in OWSM. He covers the following scenarios:

  • A basic SAML authentication with 2 OWSM Servers.
  • Change the default SAML issuer name.
  • Allow only trusted SAML clients.
  • SAML Identity switching.
  • Virtual Users with User roles.

His post provides a detailed How-To describing things step by step on how to use these features. I thought I can perhaps shed some light on when to use these features and the best practices around usage of SAML. In addition starting with Oracle FMW 11gR1 PS3 - OWSM started supporting SAML 2.0 in addition to the SAML 1.1 - I will also discuss when to use SAML 1.1 vs. SAML 2.0.

The SAML wiki provides a good general overview.

SAML versions:

There are many blog posts on the topic of what is available in SAML 1.1. vs. SAML 2.0 - so I won't go into the technical differences here. If you are interested here is a document that describes the differences. (Of course you can search with your favorite search engine for additional materials).

The general SAML specs apply for a wide variety of scenarios - beyond Web Services Security. So some of the technical differences are not relevant. The OASIS WS-Security SAML Token 1.1 Profile specification describes the relevant differences from a WS-Security perspective. (See section 3.2).

In general I would recommend people use SAML 2.0 where possible.

The technical differences maybe one of the factors that you can use to make a determination. However there are probably other aspects that may drive this decision for you. The most frequent ones we encounter are:

  1. If you are in the Government or Department of Defense sector - then in most cases SAML 2.0 is mandated.
  2. If you need interoperability with "legacy" Web Service Security stacks - then you may need to consider using SAML 1.1 as it is more prevalent. 
So to summarize - in some cases - the version you end up using may be determined by what the "other side" your partner or external entity your web service is talking to supports.

SAML Confirmation Types:

The WS-Security spec defines 3 confirmation methods for SAML:

a) Sender vouches (SAML SV for short)

b) Holder of Key (SAML HOK for short)

c) Bearer

The table below tries to summarize the key differences b/w the three confirmation methods (I copied this table from this blog as it provides a pretty succinct summary of the differences):


Method

Spec Description

English Description

Benefits

Drawbacks

holder-of-key


The holder of a specified key is considered to be the subject of the assertion by the asserting party

“Verify this signed blob to reconfirm the subject”


Strong authentication by the receiver  of the subject.


Additional per-message signature verification processing. Requires additional trust processing for the public key;

sender-vouches


Indicates that no other information is available about the context of use of the assertion


“Just trust me”


Fast and simple, no additional signature processing; if you trust the sender no additional processing is required

No additional confirmation possible; may require out-of-band or additional authentication

bearer


The subject of the assertion is the bearer of the assertion, subject to some optional constraints

“I am the subject”

Fast and simple, no additional signature processing

No additional confirmation possible; may require additional out-of-band or additional authentication

I will cover more on the SAML subject confirmation methods in the future - but the above table should be a good starting point. SAML HOK is probably most secure and provides centralized trust but is also has more performance impact and requires an STS.

In general - for public facing web services (i.e. web services) made available over the internet - I would recommend using SAML HOK. For departmental web services or web services used within the intranet - SAML SV or SAML Bearer maybe more appropriate.

SAML Identity switching

SAML is typically used for identity propagation, not for identity switching. However there are scenarios - where you may need to switch identities because you have the user id but not the password.

In general this would not a common scenario and if you want to switch identities - the general recommendation would be to use username token (or perhaps x509 token) policies.

Another thing to note is that when using SAML Identity switching policy - there is a limitation in that we don't allow propagating user roles and user attributes from the client to the service (as I mentioned in this blog post).

In a future blog post - I plan to discuss use-cases where SAML based Identity switching would be appropriate - rather than username token or x509 token.

SAML Issuer List & SAML Trusted DN

As a best practice - I would recommend people configure the SAML issuer list and the Trusted DN's for that issuer list.

The out of the box value for the list of trusted issuers is "www.oracle.com" and I highly recommend that you change this in your environment to right SAML Issuer. While OWSM provides you the flexibility of configuring the issuer of a SAML assertion on a per client basis - I would recommend configuring the issuer at the domain level (just from a manageability perspective).

Virtual User

The virtual user functionality is typically useful for products that act as intermediaries. (ex: OSB, OEG, etc). In the virtual user scenario - the user in the SAML assertion is not validated against an identity store (hence the name virtual user).

If you are using intermediaries like OSB, OEG to front-end many web services belonging to different security domains, where each domain has it's own identity store (user repository), then trying to validate the user in OSB, OEG is not very meaningful.

In a future blog post I plan to provide additional information around use-cases where virtual user functionality is typically used - but for now the key takeaway is - it is typically not useful to use this functionality for back-end web services.

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.

About

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

Search

Categories
Archives
« July 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
31
  
       
Today