persitentID nameID for specific SPs, transient for default

[Peter Schober]

* Jehan Procaccia <jehan.procaccia at tem-tsp.eu> [2017-12-14 11:59]:
> > 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*//" /

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

> So I build now eduPersonTargetedID as a simple attribute based on our ldap
> eppn value

That's certainly incorrect.

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

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

That's not a valid/correct/allowed-by-the-spec persistent NameID
value.

> so everything seems fine

It's not.

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

> 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*!?*

Use your own logs and/or the aacli tool, then you don't need external
serices to tell you what your IDP is doing.

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

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?

> 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