Using Metadata in my App

[Andy Bennett]

Hi,

>>> authenticates users to my service via the FastCGI interface. It all
>>> works well and I've configured things such that my App is delivered the
>>> attributes that it wants when a user logs in. When the first user logs
>>> in from a particular IdP the App creates an entry for the user as usual
>>> and also an entry for the IdP, currently keyed off of the
>>> Shib-Identity-Provider variable.
>>
>> I would in general strongly discourage you from basing things off of the
>> entityID other than things that specifically pertain to SAML processing.
>> Those are not really organizational identifiers. They only have meaning in
>> the context of the low level exchanges taking place.
> 
> +1
> 
> It's taken me years to fully understand why Scott consistently gives
> this good advice but now I finally understand. When site admins in the
> InCommon Federation change the entityID associated with their SAML
> deployment, this has a ripple effect, mostly for the worse.

Thanks for these tips.

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

Shib-Identity-Provider seems to equal <IdP-URI>. Is this always the
case? 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?

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.


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?



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



Thanks for your thoughts.





Regards,
@ndy

-- 
andyjpb at knodium.com
http://www.knodium.com/