[WG-FI] Question: Best practice for metadata

[Rainer Hörbe]

In our current non-SAML federation (Austrian eGovernment) we have metadata about IdPs and RPs in a central LDAP server. Each RP has a separate access control function that enables/disables an IdP. So the idea is to have a common configuration for the whole federation, and each RP can decide which IdPs to use.

What is the best practice with SAML metadata for hundreds of providers? If we have separate metadata documents per provider (at the well-know URL?), it could be cumbersome to configure them all. Do products allow to import a list of metadata URLS from a file to automate this process?

If we include all IdPs and SPs into a single signed metadata document, then the setup would be easy, but IdPs might have to be enabled per RP. Do products support this?

Thanks, Rainer
_______________________________________________
WG-FI mailing list
WG...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-fi

[Cantor, Scott E.]

> What is the best practice with SAML metadata for hundreds of providers? If
> we have separate metadata documents per provider (at the well-know
> URL?), it could be cumbersome to configure them all. Do products allow to
> import a list of metadata URLS from a file to automate this process?

Shibboleth supports any combination or number of batches and assumes third party trust to verify the metadata to begin with, which is the problem of acquiring metadata directly from an entity (there's no reason to believe it, and if you could, you likely wouldn't need the metadata).

> If we include all IdPs and SPs into a single signed metadata document, then
> the setup would be easy, but IdPs might have to be enabled per RP. Do
> products support this?

Shibboleth assumes that the peer trusts any metadata it's given, provided it verified. If IdPs or SPs need to be removed or whitelisted, there are filtering plugins for that, and on the SP side applications can always do their own things anyway.

Most SAML products have terrible support for metadata, period. The reason eGov 2.0 looks like it does is because I made one last attempt to change that. After that, I'm about done trying and will just consider Shibboleth, simpleSAML, and a few other open source variants the only viable SAML choices if you're trying to scale up with metadata. That is certainly the reality today.

-- Scott

[David Simonsen]

Hello Rainer,

You may consider a hub-and-spoke architecture?

In the federation we operate (WAYF (http://www.wayf.dk , a Danish public eID federation, >50 RPs, >110 IdPs, >4,5 mio eIDs enabled) each RP/IdP only has to know a single end point (a single, static entry in the metadata): the federation hub.

FYI: In Adalusia, Spain, a copy of the WAYF setup, dubed CONFIA (http://confia.aupa.info/) has been established - in addition to 'SIR' provided by the research network (http://www.rediris.es/sir/). Also Holland is operating a very similar infrastructure (http://www.surfnet.nl/nl/Thema/SURFfederatie/Pages/Default.aspx).

Some of WAYF's arguments for establishing this architecture are described in the paper "Trusted third party based ID federation, lowering the bar for connecting and enhancing privacy" : http://wayf.dk/wayfweb/articles.html

Also video presentations are available at: http://wayf.dk/wayfweb/video_archive.html

The most prominent benefits of the hub-and-spoke setup are: no metadata management (only a single end point), protocol independance (each entity may assyncronly change connection protocol to the fed-hub without disturbing the others), central consent service (consent to data exchange for individual users, takes away complexity from the IdPs), centrally managed attribute release profiles (takes complexity away from IdPs, enhances negotiation power).

The Corto system (https://sites.google.com/site/cortopages/) in addition enables centrally provided proxy-end-points for all RPs and IdPs, thereby mimicking a p2p-federtion (which some SAML RPs insist on), while keeping the benefits of the hub-and-spoke architecture.

The federation administration system JANUS, which is an open source module we built for simpleSAMLphp also imports metadata from URLs:
https://sites.google.com/site/simplesamlphpam/
http://code.google.com/p/janus-ssp/

You can try it for setting up both IdPs and RPs at: https://janus.wayf.dk (self service for connecting to the test environment).

Specific access rules (RP -> IdP, or IdP -> RP) can be administered via the web-interface of JANUS - as well as rules for activation of the user-consent dialog.

SimpleSAMLphp (http://simplesamlphp.org/) also has a metadata aggregation module as well as a metadata validation service which we implemented for the Nordic Kalmar2 interfederation (available to try at: https://test.kalmar2.org/module.php/kvalidate/validate.php )

I hope this may of help. If you like, we are happy to further explain, discuss and talk about all of the above - and more ;)

Kind regards
David Simonsen