Help with Persistent NameID

[Cantor, Scott]

On 10/1/18, 4:31 PM, "users on behalf of Jason Rotunno" <users-bounces at shibboleth.net on behalf of jrotunno at swarthmore.edu> wrote:

> We're running Shibboleth 3.3.x and in the past I've setup several SP's to use persistent IDs. For example:

You made up your own Format (which is invalid, you can't make up an OASIS URN), actually and that's not a suitable value for an actual SAML 2.0 persistent NameID. So that's a problem on two counts.

>             p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:persistent"

That 1.1 should be 2.0 if you're talking about the Format defined in the standard, and that has to be an opaque pairwise value, not something like an employee ID.

> employeeID as defined in conf/attribute-resolver.xml

That's the deprecated way of encoding a NameID that duplicates the other part of the configuration you posted (and still has the wrong Format). But they're equivalent and the deprecated one won't matter, it's just duplicating the other stuff.

>* Am I correct that the c:candidate value in conf/saml-nameid.xml should be the entityID in the SP's metadata?

That's not the conventional way to control data release, though it's possible and sometimes useful. Normally the underlying attribute(s) get released with a filter rule and the rest is left alone as generic definitions of what's possible. If I can't get "mail", I can't get a NameID that's built on top of it, and it's all fine. With persistent NameIDs (real ones, not yours) it's a bit more complex and it depends which services you're willing to release them to and why.

On top of all that, you're perhaps not understanding how Format selection happens, which is a separate issue and ultimately determines what it will try to do when the time comes to generate something and that's why it's just defaulting to transient. There's nothing there to tell it to do anything else.

-- Scott