idp 3.3.2, SP wants transient and persistent ID's

[Cantor, Scott]

On 11/2/18, 9:17 AM, "users on behalf of Robert Duncan" <users-bounces at shibboleth.net on behalf of Robert.Duncan at ncirl.ie> wrote:

> A non Shibboleth SP is requesting nameid's like so:

Taken literally that metadata would mean the SP doesn't require any particular form of a NameID at all, so you shouldn't give it one (or just give it a transient). When that fails, you can conclude the metadata's wrong to begin with.
 
> I'm confident that we are producing persistentID's as I can query them in the database.

Whether you are or not, the formats in metadata are treated as an ordered list and the log should show it attempting to produce/generate each format in turn and failing on each one until it hits transient and succeeds. So you are not configured to produce a persistent NameID for that SP, and I would presume the log would say that it failed trying.

> I tested with aacli, the result for the metadata above is no attributes, should I be able to view persistent ID's as 
> 'traditional' attributes with a clean install 3.3.2

NameIDs are not attributes at all. The new aacli will show the NameID produced for an SP via the ---saml2 option and usually reflects what would happen during a login. A clean install with no changes won't produce any NameID but transient. "Clean" would mean "no modifications or customizations".

-- Scott