There has been some recent chatter about the lack of strong, proven standards for API authentication when using the REST paradigm. Recent discussions seem to suggest that 2-Legged OAuth2 is the de-facto champion for securing so called lightweight web services based on the REST paradigm.
The trouble is, for all it’s hype, Enterprises looking to secure critical parts of their B2B communication and supply chain tend to view OAuth2 similar to an excited, overanxious know-it-all teenager, one that you just don’t trust quite yet.
In fact, in talking with some of our potential customers the chief complaint is that OAuth2 doesn’t have the same trusted track record as other established standards, most notably SAML. The problem is, SAML has no official binding for REST based API communication and it is often accused of being too heavyweight due to the XML and XML security processing it imposes on applications. What if there was a way to solve both of these problems for the Enterprise?
At Intel, we’ve long believed that XML is the way to go and the use of an XML Gateway decouples the expensive security, parsing, and transformation features from the developer, making things like SAML processing a snap.
About the second problem. We’ve thought about it and came up with a new feature in the latest version of Expressway Service Gateway that solves the binding problem using a simple approach. Rather than start a new OASIS group or other heavyweight process, we’re suggesting that SAML assertions, either holder-of-key or bearer, be encoded using standard base64 encoding into the HTTP Authorization header. Further, in order to provide an adequate security model, SSL is a must as the assertion itself (while it may be signed) will not be cryptographically bound into the header.
The approach is extremely lightweight and will allow any Expressway customer to protect REST APIs using SAML as the required token mechanism. On the client side, the developer still needs to generate an assertion on their own (or use a gateway product like Expressway), but if they are already using SAML as a token for SOAP messages or other purposes, the assertion is likely already available.
Let’s see how it works in the product. There are two sides to this interaction, the client and then the service. On the client side Expressway can act as a client gateway and attach a SAML assertion to a REST call. To do this, We’ve added a new REST security action to the palette.
In the previous picture, we have a new action that will do the work of creating a new SAML assertion and attaching it into the header. The next question is, how do we control the options? For this, the action is connected to a REST security policy. Here, we are specifying that the output is the HTTP Authorization header and choosing SAML holder-of-key. Remember, for the scheme to be secure, the API call must be done over SSL.
The previous two screen shots suggest a way to generate the assertion and attach it to an outbound call. What about processing it on the service side? For this, we’ve rolled the SAML for REST processing into the existing AAA action.
As you can see in the previous screen shot, all that is needed is a AAA step. The mechanics are pretty simple and extra options are available from the AAA policy – shown in the following screen shot.
In the previous screen shot, you can choose how you want to obtain the assertion. For instance, if you are grabbing the SAML assertion from a standard place (such as SOAP header), a workflow variable, or the two SAML for REST options from the HTTP Authorization header.
We’d really like your feedback and comments on this approach. We’ve already heard the requirement from a few large Enterprise customers – please let us know what you think! -Blake