persitentID nameID for specific SPs, transient for default
Jehan Procaccia
jehan.procaccia at tem-tsp.eu
Thu Dec 14 12:46:27 EST 2017
Le 14/12/2017 à 13:48, Peter Schober a écrit :
> No. I was assuming you already had an existing AttributeDefinition to
> create the eduPersonTargetedID SAML Attribute in your resolver (from
> an IPD2 upgrade, possibly).
> I don't have one such suggestion handy, maybe someone else can share a
> IDPv3-style attribute defintion to create the eduPersonTargetedID
> attribute.
> (Personally I don't use that, my IDP only supports the proper NameID
> format, not the SAML attribute. That's also easier to create in the
> IDPv3. I forgot why you couldn't make use of that and why I suggested
> the attribute variant. Possibly to stop you messing with NameIDs
> completely?)
>
I don't want to use inapropriate or old V2 solution, I just want to be
able to connect to SPs that request an edupersonTargetedID
so if NameID format in IDPv3 is the way to go , i will follow that path .
>> So I build now eduPersonTargetedID as a simple attribute based on our ldap
>> eppn value
> That's certainly incorrect.
OK, I will forget about that attribute construction
>
>> here are idp-process log when I connect now to
>> https://monitor.eduroam.org/sp
> Please stop logging on DEBUG and simply use the aacli as intended!
> I've even inluded an example invocation (with the correct entityID for
> the SP you were trying to use) in my previous email. If used with the
> --saml2 parameter you'll also see the NameID, not just the attributes.
aacli with saml2, did'nt know about that option, good advice, here it is
with previous edupersonTargetedID constructed manually from eppn :
[root at idp3 shibboleth-idp]# ./bin/aacli.sh
--requester=https://monitor.eduroam.org/sp/module.php/saml/sp/metadata.php/default-sp
--configDir=conf/ --principal=procaccia --saml2
<?xml version="1.0" encoding="UTF-8"?>
<saml2:Assertion ID="_38093625045a81e832956b4cc49d8c03"
IssueInstant="2017-12-14T17:11:51.494Z" Version="2.0"
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
<saml2:Issuer>https://idp3.tem-tsp.eu/idp/shibboleth</saml2:Issuer>
<saml2:AttributeStatement>
<saml2:Attribute FriendlyName="uid"
Name="urn:oid:0.9.2342.19200300.100.1.1"
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</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="mail"
Name="urn:oid:0.9.2342.19200300.100.1.3"
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">jehan.procaccia at tem-tsp.eu</saml2:AttributeValue>
</saml2:Attribute>
<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>
<saml2:Attribute FriendlyName="eduPersonPrincipalName"
Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6"
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>
</saml2:AttributeStatement>
</saml2:Assertion>
is that doc:
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPTargetedID
the correct one to follow to create an eduPersonTargetedID as requested
by SPs like
https://monitor.eduroam.org/sp/module.php/saml/sp/metadata.php/default-sp
that publishes in their metadata :
<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>
<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"/>
I just want to be able to give that SP what it request. I've read too
many specs, docs , best practices, i'am lost , which one should I follow
to fullfill that SP ?
>> 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
>> ...)
> FWIW, worked for me just now.
still doesn't work for me, probably because I sent it a wrong formated
eduPersonTargetedID (for now)
> Use your own logs and/or the aacli tool, then you don't need external
> serices to tell you what your IDP is doing.
ok, thanks for the --saml2 option in aacli !
>
>> 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 ?
> The way you produce persistent NameID values (and the value of an
> eduPersonTargetedID attribute *is* a NameID of type persistent, as you
> can clearly see in the XML you posted above from your DEBUG log!) has
> nothing to do with any of the topics you're asking about here.
i'am asking to produce an eduPersonTargetedID as a NameID of type
persistent to respect the desire of the SP metadata.
>
> I.e., you can generate eduPersonTargetedID attributes (or not), or
> create persistent NameIDs as intended in SAML2 (by using the IDPv3s
> saml-nameid.* support for that),
ok, I would like to support it as intended in SAML2 with my idpv3 .
> or support neither of those two,
> *fully* *independent* of whether you create them dynamically or from a
> database.
>
> Without a database you cannot support reverse mapping of those
> identifiers, of course.
I would like to start simply that way (no DB) in order to validate
access to those SPs that need that attribute .
> But you probably don't need that anyway (you'd
> know if you'd needed it). And without the abstraction layer that a
> database gives you you have no way to handle situations where a manual
> intervention would be required to prevent use of a persistent NameID
> value by another person (which strictly prohibited by the spec) or to
> prevent a person recieving another NameID value (allowed by the spec,
> but may disrupt service/data access for the subject, so not to be
> taken lightly either).
I will consider, latter on, to be conform to the spec, so I understand
that eventually I'll need a database to store mapping of persitent
NameID to real local username .
>
> If you don't have plans to add more than 1 IDP node maybe look into
> using sqlite for your IDP. (I do that myself, but it's really just a
> toy IDP serving only a couple of people.)
> That's just a simple file on disk, with no process running or any
> other maintenance. No idea whether that would scale to your
> deployment requirements, of course!
>
> IMO the less suitable your base identifier is to generate persistent
> NameID values from, the more likely it becomes you'll need to
> intervene with the mapping at some point. E.g. in case the userid you
> create persistent NameIDs from changes but you want to enable the
> subject to continue accessing services with the same persistent NameID
> values as before. Without a database (and when using unsuitable
> identifiers as a source attribute) you're screwed, with no way to fix
> that. With a database you could have the (hopefully automated!)
> processes to detect such cases and simply update the userid in the
> database, so that the new userid replaces the old one, leading to
> continued use of the previously created and persistent NameID values.
>
> Now if you neither have the processes to detect such cases (userid
> change) nor the time/interest to hande those manually, well, you
> wouldn't need the database anyway, so you might create those
> persistent NameIDs values dynamically (and not store them) anyway.
>
> Does that help?
yes , I already manage other databases (mysql and postgresql), so I
could dare to get one for that purpose now that I kind of get convince
that it's necessary .
I was initially expect to build a computed on the fly persistend NameID
for those specific and nearly unique SP (monitor.eduroam) that asked for
it, and leave all other SPs to the more traditional an simple transient
nameID.
is it what will happen if I keep declare both transient and persisten
generator in saml-nameid.xml in that order?:
<util:list id="shibboleth.SAML2NameIDGenerators">
<ref bean="shibboleth.SAML2TransientGenerator" />
<ref bean="shibboleth.SAML2PersistentGenerator" />
No need to get into CustomNameIDGenerationConfiguration :
https://wiki.shibboleth.net/confluence/display/IDP30/CustomNameIDGenerationConfiguration
nor list SPs in activationCondition
https://wiki.shibboleth.net/confluence/display/IDP30/ActivationConditions
(|||c:candidates||=||"#{{'https://sp.example.com/shibboleth',
<https://sp.example.com/shibboleth%27,>
'https://another.example.com/shibboleth'}}"
<https://another.example.com/shibboleth%27%7D%7D>| |/>|
if federation metadata ask explicitly for the correct nameIDs as is the
case with
entityID="https://monitor.eduroam.org/sp/module.php/saml/sp/metadata.php/default-sp"
I hope I will get a running config with all these advices .
If you have a sample config, I'll appreciate .
Thanks .
jehan .
>
>> I could concatenate name+birthdate or whatever with a
>> ScriptAttributeDefinition I guess
> Or Template, even simpler.
> https://wiki.shibboleth.net/confluence/display/IDP30/TemplateAttributeDefinition
>
> Cheers,
> -peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20171214/980f5ddf/attachment.html>
More information about the users
mailing list