In the article "The importance of threat protection for restful web
services", I presented a number of content-based threats for XML. When
protecting an endpoint from XML based attacks, not only are payloads scanned
for code injections, malicious entity declarations and parser attacks, XML
documents are actually validated against strict schemas that clearly describe
expected document structures. Enforcing this type of compliance at the edge,
in a SOA gateway for example, minimizes the risk of attacks of the Web
service endpoint. Structure definition languages such as XML Schema
Definition (XSD), schematron, XPath are all helpful tools in describing the
type of data and structure of XML documents that are expected at runtime.
alternative to XML and already established as the preferred content-typ... (more)
SOA & WOA Magazine on Ulitzer
Existing brokered authentication standards such as SAML Web Browser SSO or
OpenID accommodate RESTful web services for browser driven use cases.
However, what about RESTful service composition patterns where identities
need to be propagated across nested service invocations, or any RESTful Web
service client that is not browser based for that matter? How should brokered
authentication for such RESTful service calls be handled?
An interesting example of a RESTful Security Token Service (STS) was
described in March 2009 by Pablo Cibraro (aka ‘cibrax’).... (more)
I often get asked about ‘REST to SOAP’ transformation use cases these
days. Using an SOA gateway like SecureSpan to perform this type of
transformation at runtime is trivial to setup. With SecureSpan in front of
any existing web service (in the DMZ for example), you can virtualize a REST
version of this same service. Using an example, here is a description of the
steps to perform this conversion.
Imagine the geoloc web service for recording geographical locations. It has
two methods, one for setting a location and one for getting a location. See
below what this would look like i... (more)
A lot has changed about the state of OAuth since I last presented at RSA
Conference. Last year, the enterprise was screaming for standardized
mechanics to provide access control to their APIs. Back then, OAuth was
merely on the Enterprise Architect’s radar. It’s now safe to say that
OAuth 2.0 is poised to fill this gap.
OAuth 2.0 is rich –different token types to accommodate different styles.
The ‘bearer’ token type provides the simplicity of cookies, the ‘mac’
token type provides the security of hmac signatures. OAuth 2.0 also defines
many different flows to accommodate differe... (more)
One of the common misconceptions about OAuth is that it provides identity
federation by itself. Although supporting OAuth with federated identities is
a valid pattern and is essential to many API providers, it does require the
combination of OAuth with an additional federated authentication mechanism.
Note that I’m not talking about leveraging OAuth for federation (that’s
OpenID Connect), but rather, an OAuth handshake in which the OAuth
Authorization Server (AS) federates the authentication of the user.
There are different ways to federate the authentication of an end user as