A little clarification on NameIDs

[Wessel, Keith]

Thanks, Scott. So, if I don't mind anyone requesting the mail nameid in their metadata to get it without explicit filter configuration, I can set the saml-nameid configuration to unfiltered. If I'm not confortable with that but the vendor can't also handle an attribute value coming through in the assertion, I'm back to the old fallback of the second attribute definition that doesn't include the encoders.

Is that correct?

Keith


-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Friday, February 12, 2016 1:59 PM
To: Shib Users <users at shibboleth.net>
Subject: RE: A little clarification on NameIDs

> We're in the process of configuring our IDP to release a mail-formatted
> nameID to a vendor. We'd like to use the value of eduPersonPrincipalName
> instead of mail to do this, and I believe I see how to configure this in saml-
> nameid.xml.

Certainly could, yes.

> According to the docs for custom NameID generation, it's necessary to also
> release the attribute to the SP in attribute-filter.xml.

Not anymore, no. You would just set the p:useUnfilteredAttributes property on the generator. But it does default to filtered since it's a privacy exposure for most custom NameIDs.

We defaulted the persistent generators back to use unfiltered since that's just a seed and doesn't expose the seed data.

> If I do this, does it mean
> I'll be sending eppn to the SP as both the nameID and an attribute in the
> assertion? I suppose this isn't a problem unless the vendor doesn't like that
> for some reason.

It would, yes, if you released it.

> If I do need to release the value only as the nameID, is the best way to do
> that to define a second attribute in my attribute resolver config with the
> same definition but no encoders, or is there a cleaner way?

Cleaner now, that was the old workaround.

-- Scott

-- 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net