Using Metadata in my App

[Tom Scavo]

On Tue, Mar 26, 2013 at 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>.

I think you mean eduPersonPrincipalName (ePPN) is <letters>@<scope>
(but otherwise the above is correct, yes).

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

If your software is configured correctly, yes.

> If an IdP changes their entityID will the value of
> Shib-Identity-Provider change?

Out of necessity, yes. Indeed, this is where the fun begins :-)

> Will I still get the same persistent-id for that individual?

I think you mean ePPN, in which case, yes, ePPN is globally unique.

> What about targeted-id?

Technically, no, since ePTID is a triple, one component of which is
the IdP's entityID. If the ePTID value was computed correctly by the
IdP to being with, you would still obtain that same value after their
entityID had changed.

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

Actually, you're asking good questions. We rarely get such deep
attribute-related questions here ;-)

> 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. We prefer
> persistent-id when it is present. It also allows me to detect if an IdP
> moves from one method to the other and rekey the data appropriately.
> If we're keying off persistent-id we split on the ! and assert that the
> first part is equal to the Shib-Identity-Provier, the second part is
> equal to us and then we lookup or create a user which is keyed off of
> the third part and a relation to the IdP entry.
>
> From my reading of the docs at the time, that seemed like a reasonable
> thing to be doing. Is that the case or have I missed something?

Neat algorithm. Not sure if it's bulletproof. Need to think about it...

>> This becomes painfully apparent when an organization wants to deploy a
>> second IdP. Both IdPs can not have the same mdui:DisplayName, so at
>> that point it becomes clear that equating mdui:DisplayName with the
>> organization is logically false.
>
> 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
> all the IdP entries for that particular organisation as well as other
> things that my App knows about such as eMail domains for that
> organisation (which I'll supply from another source) and App resources
> that I want to make available to people affiliated with that
> organisation. I was looking for a way to prepopulate this Organisation
> list from the Federation metadata. I wanted a good interface to this so
> that I can keep up-to-date with the appearance of new organisations and
> IdPs. Clearly there will be some amount of manual tweaking of the
> organisation -> IdP mapping, especially in the case where a single
> organisation has two IdPs so I was hoping to be able to do this well
> before I saw the first logins from those IdPs.

Your goal is laudable but unfortunately the typical SAML metadata file
is not up to the task. For an interesting counterexample, see the
SWITCH metadata:

http://metadata.aai.switch.ch/metadata.switchaai.xml

Notice the value of the OrganizationName element in each case.
Brilliant, eh? :-)

Tom