saml metadata interchange avoiding the martians tying trust rules to associate entities
Wed, Oct 15, 2008
Ian Young has some interesting ideas on metadata interchange between federations, which you can read here. It deals with aggregating metadata from entities in different federations, making them appear as if they are part of a specific federation. As I’ve just finished implementing federation sensitive metadata and trust handling for Guanxi, I might as well digest the proposal and give my opinion on the matter. What’s that you say? Opinion? Surely a rant? Not this time I’m afraid. I thought it would be interesting to approach it from a software point of view. Ian is proposing a federation could aggregate metadata for all entities that are members of another federation, much in the same way it aggregates metadata for its own members, as in the case of the UK Access Management Federation metadata. As this doesn’t happen at the moment, entities who live in multiple federations must aggregate the metadata themselves. This can be seen quite nicely in the Guanxi IdP and SP, where you can register local entities, if you want to do local testing or just want a local intranet of entities:
The trust engine is there to make sure the appropriate rules are followed for each source of metadata. So a Service Provider (SP), in Federation A may have different validation and trust rules (PKIX) than an SP in Federation B (custom rules) and the IdP must be able to apply the appropriate rules. As far as the software is concerned however, there are no such things as “federations”. A federation is a convenient grouping of entities where the rules of the club are defined and one must roll up one’s trouser leg and dance on one leg to gain membership but that has nothing to do with the software that implements the entities within the federation. The hopping on one leg is the federation trust at the bod layer. Once you’re past that, you can forget about federations as the published metadata for all entities who’s owners have hopped on one leg can be trusted, usually via a digital signature on the metadata aggregation.
What you do have to take account of, are the trust rules at the entity level. If we say Federation A is the UK Access Management Federation and Federation B is a local grouping of entities directly registered with the IdP via its registration interface, then it’s clear that the simplistic rules for trusting entities in Fed B MUST NOT be used with entities in Fed A. This might seem a contrived example as locally registered entities are a Guanxi thing but no doubt we’ll see high security federations with vastly more complicated trust rules than the UK federation rules.
Now that we’ve set the software scene, let’s get back to Ian’s proposal, where federations aggregate metadata for all entities, including roving ones or “associate entities”, you might say:
With Metadata Interchange, Fed B has a presence in Fed A’s metadata but we can see straight away the trust rules are broken. Well, to be more precise, the current “trust profile implementation” cannot handle Metadata Interchange. The current profile ties trust to metadata source. The source in this case contains entities from a high security federation (B) but the rules of trust for A’s metadata source are less severe, providing a back door into B’s entities. In Ian’s paper, the two SPs connected by dashed lines are “mobile entities”, or “associate entities” as I’ve called them. Luckily, Ian also proposes a separate metadata aggregate, which would bring trust tied to source back into play:
In our hypothetical world, this would allow some entities of Fed B to appear in Fed A but maintain their highly secure trust models. This assumes we’re using metadata source to define trust rules but perhaps the profile could include new metadata extensions? But that would require defined trust rule names to be published. Much in the same way Shibboleth defines a urn:
could a trust urn be defined?
Thinking about it, the current scenario is prolly a bit more flexible, where an ingest of metadata is tied to specific trust rules based on where it came from. However, the proposal now takes a turn for the worse, as one single grouping of associate entities is being proposed, where Fed A publishes one extra metadata aggregation which includes entities from Fed B and Fed C:
You can see that the trust rules have broken down again. There’s no way to tie trust to metadata source as the metadata now covers two federations. A high security federation (B) and a cheapo, we’ll let anyone in, corner shop federation ©. Ian even refers to these cheapo feds when talking about multi-homing, where an entity registers with multiple federations. Why bother, if metadata can be interchanged and “Walmart” federations spring up offering cheap registration, much in the same way that Google offer extremely cheap domain registrations. Once you have your domain, you’re on the net. Once you register with a “walmart” federation, you can roam wherever you’ll be accepted as an associate entity.
That’s all fine and just market forces but the problem is tying trust rules to associate entities. Taking it further, Ian states:
“each federation would publish metadata which was the union of the metadata of entities it had registered combined with the metadata of all entities registered by other partner federations”
that’s fine as long as the trust rules are the same across all those participating federations. If one SP in one “associate federation” requires weird trust rules, it all breaks down. As an analogy, it’s like sitting down to dinner with your family and your maw brings in Uncle Scarab and his weird looking kids and announces, “folks, this is your Uncle Scarab from Mars, say hello” and your Martian relatives proceed to go “ga gaaa gaa gaa ga”. Who knows what might happen:
but Ian then heads back in the right direction when talking about asymetric mobility, i.e. only SPs become associate entities in Fed A but we’ve still got the Martian Question, framed above. But the Martians can be kept at bay by a late statement in the proposal:
“elements specifc to the destination federation may be added, for example to indicate the source of the metadata”
I think this is pretty much required and you prolly agree too if you’ve reached this far and not disappeared off into youtube looking for more martians. In terms of the Inter-Federation Metadata Profile, Ian says:
“key material must be embedded rather than referenced by KeyName”
I say hoorah to that as it covers the easier validation options, getting rid of the requirement for PKIX.
Ian finishes off by introducing the concept of an Aggregation Appliance, which lives within a specific federation (A) and will be responsible for aggregating metadata from other federations (B and C) and publishing metadata on all entities, both native to Fed A and mobile from B and C in the appropriate format. This in effect creates a “virtual federation”, or “super-federation”:
So it’s an interesting proposal and if the issues about trust I mentioned are addressed, it could be a useful addition to the federation landscape. Just watch out for those martians along the way…