[mdx] OCLC Use case

[Cantor, Scott]

On 9/17/12 1:31 PM, "Andy Dale" <dalea at oclc.org> wrote:
>
>Then we have a few (50-60) entities that have both IDP and SP descriptors.

Do you mean "entity" here or "organization"? The typical reason for
actually having a single entity with both roles is when something is a
gateway. That doesn't seem to fit your case.

>What I was planning pre-MDX discovery was a simple extension to the SAML
>Metadata ³Well Known URL². It seems to me that SPs to such a large
>federation can reasonably be expected to Œjust deal with¹ the
>complexities of the large metadata. Originally, in my mind,
> this meant that they had to download the massive Metadata file parse it
>and make it useable for themselves. For the OCLC SPs that meant that we
>retrieved and parsed out the metadata every 4 hours and exploded it into
>a relational database.

I can see an organization like OCLC doing that, but if your expectation is
that these IdPs would be something other SPs would have to leverage,
that's never going to happen much. In fact, you have the basic problem
that they won't have much of anything they can use unless they're running
one of a handful of open source SAML stacks.

I can't tell if that's a problem for you or not.

>I have no problem making these demands of Œbig SPs¹, I believe that they,
>like us, have technical sophistication to integrate a solution that is
>more complex than Œjust point your implementation at an XML file¹.

Sadly not. I think you're overstating their willingness to do such work.

>I worry more about the IDPs. While many of the IDPs are hosted by us
>there are many that are not. I believe that the majority of those IDPs
>not hosted by us use IDP implementations that expect a simple URL to be
>configured as their metadata endpoint and are not implemented to expect
>or robustly support Œmassive¹ metadata files.

You'll find that even if they support metadata, they may not use it the
way you think they might.

> My solution to this is to provide each IDP with it¹s own metadata
>endpoint that retrieves the metadata that it is likely to need. It is my
>supposition that most of the IDPs never care about any of the other IDPs
>and MOST of the SPs that are for Œinternal use¹ don¹t care about the
>majority of IDPs. As such I speculate that a metadata endpoint that
>retrieves: ³All entities that have SPSSODescriptors and My Entity² is
>good for most IDPs.

In general, a party needs metadata not for itself, but for the peers it's
federating with. So yes, the IdPs don't want to know about the rest of
those IdPs, and that's pretty easy to do even without MDX. It's difficult
to say with IdPs the SPs will need without more information.

>The metadata endpoint configuration of the Œsimple¹ IDP for entity
>³http://example.org/idp² would be something like ³<<metadata base
>url>>?type=simpleIDP&entity= http%3A%2F%2Fexample.org%2Fidp².(This is
>meant to be logical
> not physical I¹m sure those values should not be on the querystring but
>I¹m trying to vet the idea, not the details... yet).

I think we figured that some obvious well-defined tag values might be to
query based on role.

>In OCLC¹s case this would result in metadata files that have maybe 100
>entities rather than 40,000 and I believe that it would provide
>everything that the Œsimple idp¹ would ever need, in a single static url.

I think you'll be dismayed at how few actually work even that well, to say
nothing of what they're doing with the metadata and how interoperable that
is.

>The big question in my mind is: how generalize-able is our situation?  Is
>there something here that is worth incorporating into the MDX real or it
>is just too specific to our particular needs?

All I really see is the role issue, which is a pretty obvious tag.

-- Scott