[mdx] OCLC Use case

[Andy Dale]

As I stated earlier we have a federation with about 20 thousand members and
this will soon grow to more than 40,000. The entities can easily broken down
into 3 categories:

The vast majority of our entities are IDPs only. These are libraries (public
and small academic) who are SAML enabling their patron populations solely
(at this point) to work with OCLC services and a few other select service
providers. (We are trying to break the chicken and egg cycle. By enabling a
large quantity of IDPs in the space we hope that it will help incentivize
other content and service providers that the investment in SAML
infrastructure is worthwhile. )

The other extreme of our entities are those that are SPs only. We have maybe
10 entities that just publish SPSSODescriptors.

Then we have a few (50-60) entities that have both IDP and SP descriptors.
These entities are only publishing the SP for Œinternal use¹. The primary
use case for us is an institution¹s EZProxy Server being configured to use
the institution¹s new IDP for authentication rather than a text file with
username and passwords on that machine.

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. We
provide an internal metadata service RMI API that lets us query the the
metadata based on entity_id and the specific information required, the
information in this case is returned as Java objects. I could easily see
swapping out this SP implementation to one that leverages MDX to get the
targeted metadata, on demand, from the source. Transaction times and
availability of course being something we would have to look at. 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¹.

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

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

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.

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?

With all that said; for our SPs the MD-query will be what we want to use.
I¹m just wandering about the simplification for the IDPs.

What do you think?

Andy



   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.iay.org.uk/pipermail/mdx-iay.org.uk/attachments/20120917/f3acfbf4/attachment.htm>