Variations on a Theme: SOA Security Best Practices

Since posting at OOW, I've had a few follow-up discussions - inside and outside or Oracle - about the architecture I presented there. I think the main point I wanted to convey was that there is not a one size fits all for SOA Security - or any security for that matter. That having been said, I would like to comment on two variations which have been suggested.

1 - Instead of using OWSM to protect an end-point could I use OSB?

OWSM (Oracle Web Services Manager) and OSB (Oracle Service Bus) are complimentary technologies. This is not exclusively an either or situation. For example, for public facing web-services, using OWSM to protect the perimeter makes sense. This is the SOA equivalent of using Web SSO (like Oracle Access Manager) to ensure only authenticated traffic accesses the network. Assuming that the services are hosted in OSB, and accessible from inside of the network, it makes sense to have some security on these services as well. In OSB, different proxy services can have different security policies even though they point to the same business service.

So in summary, I could have used OSB instead of OWSM+WLS in my OOW demo. I could have also used both. The scenario was an employee intranet calling out out-sourced HR provider. That HR service publicly exposed on the internet make sense for OWSM+OSB architecture described above.

2 - Instead of using SAML to pass identity from application to could I use my Web SSO token?

In the demo, I used the Credential Mapping capabilities of WLS to generate a SAML assertion, but what if you're running on a container/Web Services client stack that doesn't have that feature? Is there any issue with just passing the SSO cookie in the HTTP header or as part of WS-Security using BinaryToken profile?

There are two separate issues here - the first is the quality of the token (Web SSO vs SAML) and the second in message level security.

Both SAML and Web SSO cookies have some ability to prevent being re-used unauthorized ways - IP Address Checking or Audience restrictions - and have some notion of timeout - Session Timeout or Validity periods. I think one issue when choosing SAML vs. Web-SSO is the duration of the transaction. For example, in the demo, let's assume that the large raise service required approval. In this case, by the time the transaction is approved, it's quite likely that the Web-SSO ticket has expired. A SAML assertion generated for the specific purposes of the transaction could have a longer validity period - weeks. Regulations like PCI require sessions to timeout in 15 minutes.

Regardless of token, to ensure that the credentials are not mis-used, the digitally signing the message essentially "staples" the credential to the message. Taking the credential and adding it to a different message will not work. This ensures that the token - SAML or otherwise is used appropriately. This and other techniques are covered in some detail in the WS-Security SAML Token Profile.

So, in both of the two variations, the answer is "it depends". I wish it was more straight-forward, and I had some universal best practices. I'm happy to share my thoughts on this blog or elsewhere - preferably some place warm :)