[mdx] OCLC Use case

[Andy Dale]

I'm happy to reduce this to a role tag. Is this the same as the extended
syntax that is already being discussed? If so, how might the metadata url
look?

I assume that the semantics are something like 'give me a signed SAML
metadata document that includes only those entities that include
SPSSODescriptor Roles' am I understand it right?

Thanks,

Andy




On 9/17/12 11:07 AM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

> 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
> 
> 
>