Using Metadata in my App

[Cantor, Scott]

On 3/26/13 8:20 AM, "Andy Bennett" <andyjpb at knodium.com> wrote:

>At the moment I get Shib-Identity-Provider which is a URI and either
>targeted-id which is <letters>@<scope> or persistent-id which is
><IdP-URI>!<SP-URI>!<letters>.

It's whatever you choose to serialize it into with the software via the
decoder rule. The underlying data is a SAML NameID element in XML with a
three part structure, value, SP qualifier, and IdP qualifier.

The first thing you probably need to do is read this:
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPTargetedID

That explains why there are different syntaxes floating around this and
what "targeted-id" is (a legacy name for a broken syntax that was
accidentally adopted).

None of what you're talking about is eduPersonPrincipalName (responding to
Tom). Different attribute with different properties entirely.

>Shib-Identity-Provider seems to equal <IdP-URI>. Is this always the
>case?

In practice. Not in terms of the definition of SAML persistent IDs, no.

> If an IdP changes their entityID will the value of
>Shib-Identity-Provider change? Will I still get the same persistent-id
>for that individual? What about targeted-id?

The value is the opaque part. The qualifiers are the entityIDs. If those
change, the qualifiers usually change. How that affects your application
depends on what you do with the data. You might have to rekey, yes.

And targeted-id is broken, by definition. You can read the page I pointed
to and see how to avoid ever seeing it.

>I find it quite challenging to work through the attribute-map.xml and
>get a good idea of what will actually end up in my FCGI Variables.

I can't really respond unless I know what it is you're confused about in
the file. The most confusing thing is the nonsense around persistent and
targeted IDs.

>When a user logs in I look up or create the IdP entry based on
>Shib-Identity-Provider. This entry tells me whether we like to use
>targeted-id or persistent-id as the key for these users.

You may not need to do that if you decode the broken form into a form that
looks the same as the non-broken form.

>This is similar to the case my original eMail was trying to target. I
>currently have a bunch of IdP entries in my database and I want to
>create a bunch of "Organisation" entries and then associate them with

That's a perfectly fine thing to want, but neither the entityID nor
anything that's in SAML metadata is an organizational identifier. The
history of such things is that we have no standard for such a thing,
because every application tends to have its own views of what it's trying
to identify. There are many, many schemas for identifying organizations,
but they don't span applications.

I think, personally, that federation creates an opportunity for revisiting
that question because so many different applications rely on this common
infrastructure. But we haven't done it, and even if we did, no other
verticals would probably follow us, which puts the SPs in the same
situation, no common standard.

-- Scott