Using Metadata in my App

[Andy Bennett]

Hi,

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

Maybe... Some IdPs send me an opaque targeted-id, some send an opaque
persistent-id triple and some send a less opaque eppn plus and opaque
targeted-id. These are the FGCI Variable names. These entries from
attribute-map.xml might be relevant:

-----
    <Attribute name="urn:mace:dir:attribute-def:eduPersonPrincipalName"
id="eppn">
        <AttributeDecoder xsi:type="ScopedAttributeDecoder"/>
    </Attribute>
    <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" id="eppn">
        <AttributeDecoder xsi:type="ScopedAttributeDecoder"/>
    </Attribute>
-----


-----
    <!-- Second, an alternate decoder that will decode the incorrect
form into the newer form. -->
    <Attribute name="urn:mace:dir:attribute-def:eduPersonTargetedID"
id="persistent-id">
        <AttributeDecoder xsi:type="NameIDFromScopedAttributeDecoder"
formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQua
lifiers="true"/>
    </Attribute>

    <!-- Third, the new version (note the OID-style name): -->
    <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" id="persistent-id">
        <AttributeDecoder xsi:type="NameIDAttributeDecoder"
formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQualifiers="t
rue"/>
    </Attribute>

    <!-- Fourth, the SAML 2.0 NameID Format: -->
    <Attribute
name="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
id="persistent-id">
        <AttributeDecoder xsi:type="NameIDAttributeDecoder"
formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQualifiers="t
rue"/>
    </Attribute>
-----



I'm not using this one:
-----
    <!-- First, the deprecated/incorrect version, decoded as a scoped
string: -->
    <Attribute name="urn:mace:dir:attribute-def:eduPersonTargetedID"
id="targeted-id">
        <AttributeDecoder xsi:type="ScopedAttributeDecoder"/>
        <!-- <AttributeDecoder
xsi:type="NameIDFromScopedAttributeDecoder"
formatter="$NameQualifier!$SPNameQualifier!$Name" defau
ltQualifiers="true"/> -->
    </Attribute>
-----


I don't bother with REMOTE_USER but that seems to be configured along
the lines of (eppn || persistent-id || targeted-id). Indeed, in
shibboleth2.xml I have:

-----
    <ApplicationDefaults entityID="..."
                         REMOTE_USER="eppn persistent-id targeted-id">
-----




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

...but I don't get access to the raw ePPN from the SAML exchange. I just
get some decoded value that involves the entityIDs from "various"
places. It's not clear to me whether those entityIDs come from the
configuration (shibboleth2.xml for SP-ID, federation XML for IdP-ID) or
from the SAML exchange / IdP database backend.


>> 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'm confused. How is that different than from persistent-id? Surely
anything involving the entityID will change?


>> 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 ;-)

I seem to have got better at reading during the course of this thread.
Writing is still a challenge: I'm glad Peter Schober wrote me some
entries. ;-)


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

Thanks. :-)


> 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? :-)

That looks interesting. The OrganizationName seems to be terse but
potentially helpful and then they supply human readable names in a
number of languages in the OrganizationDisplayName attribute.
It looks like they keep OrganizationName the same for multiple IdPs and
SPs from the same organisation. Who knows if they guarantee it.



Thanks for your help! It's been really useful.





Regards,
@ndy

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