persitentID nameID for specific SPs, transient for default
Jehan Procaccia
jehan.procaccia at tem-tsp.eu
Thu Dec 14 05:58:19 EST 2017
Le 13/12/2017 à 22:05, Peter Schober a écrit :
> * Jehan PROCACCIA <jehan.procaccia at tem-tsp.eu> [2017-12-13 18:53]:
>> indeed in the edugain federation metadata, the SP does ask for a
>> NameIDFormat to be persitent (and (or ?)) transient
> The Shibboleth IDP will use the first format listed that it can
> support. So if you configuired your IDP to support persistent NameIDs
> there'd be nothing else for you to do/change in this case (persistent
> listed before transient in NameIDFormat).
OK, I understand that because NameIDFormat in edugain metadata list
persitent before transient
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
then , no matter the order beans are defined in my saml-nameid.xml (here
transient before persistent)
/ <util:list id="shibboleth.SAML2NameIDGenerators">//
// <ref bean="shibboleth.SAML2TransientGenerator" />//
// <ref bean="shibboleth.SAML2PersistentGenerator" />//
// <bean parent="shibboleth.SAML2AttributeSourcedGenerator"/
that's the order in metadata that will decide wich one to use .
>
> But the SP in question (the "https://monitor.eduroam.org/..." one)
> also supports the eduPersonTargetedID attribute,
yes, I didn't realised in the first place that in
<md:RequestedAttribute Name="urn:oid:*1.3.6.1.4.1.5923.1.1.1.10*" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/>
oid 1.3.6.1.4.1.5923.1.1.1.10 stands for : eduPersonTargetedID ! (cf
https://www.internet2.edu/products-services/trust-identity/mace-registries/internet2-object-identifier-oid-registrations/)
> so instead of messing
> with NameIDs you can simply generate the attribute as you always did
> and release it via the attribute filter, as you always did.
you mean as a /AttributeDefinition xsi:type="//*ad:Simple*//"/, and not
necessarely as/AttributeDefinition id="eduPersonTargetedID"/ of type
/xsi:type="//*ad:SAML2NameID*//"
//*nameIdFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent*//" /
I've probably been missleaded to that complexity of persitent NameID
because of perhaps old docs ?
https://services.renater.fr/federation/docs/installation/idp3/chap11#creer_un_attribut_persistentidedupersontargetedid
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPTargetedID#NativeSPTargetedID-SAML2.0Attribute
So I build now eduPersonTargetedID as a simple attribute based on our
ldap eppn value
<resolver:AttributeDefinition id="eduPersonTargetedID"
xsi:type="ad:Simple"
sourceAttributeID="eduPersonPrincipalName">
<resolver:Dependency ref="myLDAP" />
<resolver:AttributeEncoder xsi:type="enc:SAML1String"
name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" />
<resolver:AttributeEncoder xsi:type="enc:SAML2String"
name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10"
friendlyName="eduPersonTargetedID" />
</resolver:AttributeDefinition>
but still not sure if I need to use /AttributeEncoder
xsi:type="enc:SAML2String"/ or /AttributeEncoder
xsi:type="enc:SAML1XMLObject"/ ?
here are idp-process log when I connect now to
https://monitor.eduroam.org/sp
/
//2017-12-14 11:06:35,647 - DEBUG
[net.shibboleth.idp.attribute.resolver.AbstractAttributeDefinition:247]
- Attribute Definition '//*eduPersonTargetedID*//': produced an
attribute with the //*following values
*//[StringAttributeValue{value=procaccia at tem-tsp.eu}]//
//2017-12-14 11:06:35,688 - DEBUG
[net.shibboleth.idp.attribute.filter.AttributeRule:177] - Attribute
filtering engine
'/AttributeFilterPolicyGroup:ShibbolethFilterPolicy/AttributeRule:_31e435e70cb69d038291a0f733a06691'
//*Filter has permitted the release of 1 values for attribute
'eduPersonTargetedID'*//
// <saml2:Attribute FriendlyName=//*"eduPersonTargetedID*//"//
// Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10"
//*NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"*//>//
// <saml2:AttributeValue//
// xmlns:xsd="http://www.w3.org/2001/XMLSchema"//
//xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xsd:string">procaccia at tem-tsp.eu</saml2:AttributeValue>//
// </saml2:Attribute>//
//2017-12-14 11:06:43,744 - INFO [Shibboleth-Audit.SSO:241] -
20171214T100643Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|//
//|uid,mail,//*eduPersonTargetedID*//,eduPersonPrincipalName||_7078212a76e5317000482206b25264955/
so everything seems fine, howerver I still cannot verify access to the
service as of
https://monitor.eduroam.org/sp/module.php/saml/sp/saml2-acs.php/default-sp
end up on a HTTP ERROR 500 !? (perhaps a pb on their side currently ...)
and Renater test attribute page
https://test.federation.renater.fr/test/ressource does works fine but
doesn't show me the *eduPersonTargetedID ,
*neither the consent module, before sending attributes, it only showed
me**uid,mail,eduPersonPrincipalName and not eduPersonTargetedID*!?*
I'll wait for monitor.eduroam.org , perhaps a maintenance state ... ,
but it still strange to me why attribute viewer test service don't show
my eduPersonTargetedID*
*If I did it wrong , please let me know .*
*
>
> I'm pretty sure the same applies to the other SP by RENATER,
> https://services.renater.fr/shibboleth as that shows no sign of
> requiring a persistent NameID, and also not an emailAddress-type
> NameID as you have configured for that service.
>
> I highly doubt that RENATER Would really require custom modifications
> to all their member IDPs in order to let them access this SP. In SAML
> Metadata that SP requires "mail" via RequestedAttributes, so again I'd
> simply ignore NameIDs here and release the mail attribute, same as for
> every other service that needs the subject's email address.
yes mail attribute is released correctly for those SPs
>
> So ignoring NameIDS seems to be the proper way to deal with both of
> your cases.
again, maybe I've been missleaded by "old docs/practices " ? , but still
I see lot of IDPs owners in my community generating that
eduPersonTargetedID persitendID on a DB (storeID)
I am not following that path until now for reason of simplicity and not
having to manage a DB (spof) ,
Is that persitendID with associated storeID a best practice ?
>
>
>> my problem is that I need to generate an eduPersonTargetedID for
>> some SPs and I don't want to have a storeID in a DB used for each
>> and every connexions, and don't dare to manage a DB for those rare
>> usages So I want to generate that eduPersonTargetedID as a
>> computedID on the fly and use it only for a "whitelist" of specific
>> SPs
> You can do the same with "proper" persistent NameIDs, i.e., generate
> them algorithmically. Release is triggered via NameIDFormat elements
> automagically, but you can override that in multiple ways (activation
> conditions, relying party overrides) if needed.
>
> As explained above (and you should just ask RENATER instead of having
> me speculate or do guesswork on your own part) this SP is unlikely to
> need NameIDs with the format
> urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
>
> (I'll refrain from commenting on the synax as I've managed to avoide
> activationConditions everywhere so far.)
>
>> # For computed IDs, set a source attribute and a secret salt:
>> idp.persistentId.sourceAttribute = mail
>> idp.persistentId.useUnfilteredAttributes = true
>> # Do *NOT* share the salt with other people, it's like div ?ulging your private key.
>> idp.persistentId.algorithm = SHA
>> idp.persistentId.salt = secret
> Well, obviously (?) email addresses make a very bad basis for
> persistent NameIDs (same for eduPersonTargetedIDs) as commonly they'll
> change once a person changes parts of her name or her userid. At least
> you could combine that with another attribute in the attribute
> resolver that's unlikely to be the same for another person with the
> same name/userid, e.g. birth date. (Contatenate email+birthdate in a
> new AttributeDefintion and make that the sourceAttribute for your
> persistent NameIDs and for eduPersonTargetedIDs.)
for now, to debug, i've built my attribute based on eppn, but if it
finnaly works, you're right , I could concatenate name+birthdate or
whatever with a ScriptAttributeDefinition I guess :
https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverScriptAttributeDefinition
>
> And of course instead of setting useUnfilteredAttributes=true you
> probably should simply release the email attribute to the SP, which
> would then trigger the release of the email attribute-based NameID.
yes found in
https://wiki.shibboleth.net/confluence/display/IDP30/CustomNameIDGenerationConfiguration
"/The process above requires that you explicitly release the attribute
to use as a source in your filter policy. If you wish, you can avoid
this step by using a generator property (//|useUnfilteredAttributes|//)
that allows an unreleased attribute to be used as a source, but note
that doing so creates a sort of "pseudo-policy" exposing information to
an SP outside of the normal filtering process./"
Thanks a lot .
jehan .
>
> Best regards,
> -peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20171214/4b4d07f3/attachment.html>
More information about the users
mailing list