Using Metadata in my App

[Peter Schober]

Scott already commented on the conceptual issues, a few practical
notes below (if you still want to know about the "what" and "how").

* Andy Bennett <andyjpb at knodium.com> [2013-03-26 00:14]:
> ...and have not felt too enlightened about how to achieve this so
> I'm writing here for some pointers about the approach I should be
> taking and where to find appropriate documentation.

Here's an example for shibboleth2.xml:

Add metadataAttributePrefix="idp-" to your ApplicationDefaults element.
Add a Metadata AttributeExtractor below the other extractors, e.g.:

<AttributeExtractor type="Metadata" DisplayName="name"
  Description="desc" InformationURL="infourl" OrganizationURL="orgurl">
  <Logo id="logo" formatter="$_string"/>
</AttributeExtractor>

This will populate idp-name, idp-desc, idp-infourl, idp-orgurl and
idp-logo iff the referenced data is available in SAML metadata.
Everything except orgurl refers to the MDUI metadata extensions
http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-metadata-ui/v1.0/sstc-saml-metadata-ui-v1.0.html

> I have my Federation supplied metadata in an XML file in
> /var/run/shibboleth/ When I look in this XML file I see data that I'd
> like to take advantage off. Specifically, the data in <Organization>
> such as <OrganizationName>.

See above. Note that what institutions and federations have
traditionally put into these elements varies quite a bit, which is why
MDUI is always preferrable. If entities in your federation don't have
MDUI data available (as seems to be the case for the UK Federation,
the only federation I see your SP as a member) maybe talk to your
federation operator about plans/options and suitability of any (MDUI
or non-MDUI) elements for your purposes.

> >From reading NativeSPAttributeExtractor it seems possible that I could
> cook up some kind of extractor for these data and then when the users
> log in, and only when the users log in, I'd be able to get hold of that
> data. If it changes in the mean time I'd be out of luck. I'd also only
> be able to populate my app with information about IdPs from which users
> have actually ever logged in.

Same for any data/attributes revieved via SAML WebSSO.

Also these are in fact data protection/privacy features so you can't
just grab all the data (any time you want) about all subjects of an
institution, even if those subjects have never used your service.
You can update data on the next access. If you need the data in
between visits you may cache/store it in your application (Provided
there's a legal basis for that, cf. 95/46/EC).

If the institutions or their subjects actually want to you have
wholesale access to all their subjects' information any time you want
they can open up access to e.g. an LDAP directory service (and make
use of some of the eduPerson attributes specific to that).
Or look at this from the perspective of provisioning, where there's
SPML, SCIM and other standards (or standard developments).

> What I'd really like to do is to prepopulate the IdP data in my app so
> that I have an App object for hanging other data off of such as "This
> IdP and these eMail domains identify users as belonging to this
> institution", "this is the name/logo/description of this institution"
> (for cases where it's not supplied by the IdP) and "these are App
> objects for users of this institution". i.e. data that I obtain through
> other sources.

The software doesn't keep you from doing any of that. Unless the data
is available to it in a standardized way (i.e., SAML metadata) it
won't make it magically appear, either.

Cheers,
-peter