Category Archives: Security

APIs and Alan Moore Characters

It was originally intended to be a straightforward conversation about APIs, but thanks to Ian Murphy of Enterprise Times several Alan Moore characters managed to enter the discussion. Magic is certainly something we can all use in organizing our APIs and automating our processes.

Failing that, it’s important to cut ties with the past and implement best practices for an API first design approach, to ensure the APIs provide the service the consumer needs and wants. Just wrapping existing code with an API is unlikely to cut it, although this is a tempting shortcut. Generally in this area however, you get what you pay for.

It’s also a lot better to take security into account from the start, rather than having to redo things and remediate potential vulnerabilities just as you are about to deploy to production.

And it’s very intersting that we are basing our APIs on REST now – understandable, of course, but interesting that the best practices for HTTP (which embodies RESTful principles) evolved from a completely different stream of technology development than WSDL-based Web services and traditional middleware.

As unexpected as it might seem, if you think about it, Alan Moore’s dr & Quinch characters are a good fit for the kind of chaos monkey style of resiliency testing helpful to improve the stability of APIs.

And – thanks for this one Ian – who initially thought of Mina Murray as the best one to impress upon independent minded developers the need to follow a common purpose, just as she did for the League of Extraordinary Gentlemen. I’m just as sure she would be capable as I am that some API dev teams would benefit from such leadership. This is a constant challenge with dev teams, of course. Just not sure everyone really needs a vampire to lend a hand.

Anyway , it was great fun to approach the topic this way, and I hope Ian won’t mind if I mention that he told me he has actually seen one of Alan’s spoken word performances. I’m sure that was really cool, and potentially disturbing.

Now, I only wish old Moore titles would increase in value the way DC and Marvel title recently have, since he is by far the best writer in the field today. Maybe this has something to do with movies…

Enterprise Integration Patterns for Security

It seems like the Enterprise Integration (Security) Patterns Fred came up with went over pretty well at the Unatek Conference earlier this month.

Last October Fred and I published an article on Handling Multiple Credentials in an Heterogenous SOA Environment and since that was well recieved I thought it might be a good topic for the conference keynote.

Naturally, I asked Fred to help 😉 and he came up with the following three enterprise integration security patterns:

  • Message Protection
  • Token Propagation
  • Token Mediation

These patterns capture solutions to common security challenges when dealing with multiple protocols and credential formats. These challenges frequently occur in an SOA environment that integrates multiple middleware technologies, such as Web services and CORBA, or Web services and J2EE (which actually amounts to pretty much the same thing since J2EE incorporates CORBA’s interoperability protocol, IIOP, and the security credential format from CSI_V2, another CORBA standard).

Consider the scenario in which a service request using SOAP/HTTP invokes a second request using CORBA or J2EE in order to complete its work. Security considerations include the use of an encrypted form of HTTP (i.e. HTTPS) and IIOP with SSL to protect the message content, but with two different protocols there’s a potential vulnerability at the intermediary (i.e. the place where the HTTPS connection ends and the IIOP/SSL connection begins). The message protection pattern defines how you address this scenario.

Message protection diagram

Another challenge is handling multile credential types, for example the username/password format in WS-Security and the CSI_V2 format in CORBA/J2EE. Multiple credentials can be aggregated into a common data structure and included in the request context, or one credential can be mapped to another at an intermediary. But the credentials are vulnerable to impersonation at the intermediary. Another alternative is to use WS-Trust or the equivalent to “federate” the incoming token with the new token. The token propagation and token mediation patterns describe the solutions for these.

Token propagation diagram

Token mediation diagram

WS-SecurityPolicy can also help, although to be really useful in heterogenous environments extensions may need to be added to represent credential and key information not in the current spec. However since WS-Policy is essentially a publishing mechanism that describes the capabilities of a service provider, care must be taken to protect sensitive information.