Security Services Deployment in Federated World

Its easy to get hung up on security protocol design, finding the right fit for your architecture and so on. Its really hard to find security mechanisms that do something useful and scale as well. In my opinion, this is the single biggest issue we face in security today - how do find useful things that solve security problems, that can scale in real world systems.

To that end, my favorite paper in a long time was written by Patrick Harding, Leif Johansson, and Nate Klingenstein called "Dynamic Security Assertion Markup Language: Simplifying Single Sign-On." They begin by asking questions companies face when entering into a federation:

How should trust between providers be managed? 

How should information about providers (metadata) be provisioned? 

Which SAML profiles and bindings should be used? 

Which messages and what part of each message should be signed? 

Which identifiers and attributes should be exchanged? 

What are the semantics of those attributes and identifiers?

Organizations understand the benefits of SSO and federation, but don't always answer the above questions in a way that sets them to scale. Harding, et al.'s work describes a way to partition the architecture into separate layers - a metadata trust fabric,a metadata publishing fabric, and a metadata validation and signing fabric - enabling dynamic federation. If you design stuff for a large scale distributed systems, this is a really big deal. No wonder these guys win all the good awards. 

I have often used Federation as an example of security as a business enabler - improving the brakes, ABS, and airbags so we can drive fast and safe. Federation creates value for the business through more deeply linking it with its customers, partners, and business users; it solves some security architecture problems through encrypted and signed tokens; and it gives the user SSO/SLO. You don't always get a win like this in security architecture, but when you find one its good to ride it for all its worth.