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.
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
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.
I will address Mobile Clients in a future blog post.