Using a custom attribute as the eppn

[Cantor, Scott]

> Scott, I work on the application in question (Dataverse) but I'm
> having trouble understanding what you want. If you're saying that
> Dataverse should be more flexible in accepting a variety of attributes
> to uniquely identify users such as eppn, ePTID, NameID, and others, I
> have already opened an issue about this at
> https://github.com/IQSS/dataverse/issues/1422 and comments are very
> welcome!

I'm saying that the *header names* used at an SP are arbitrary. That's a local configuration decision. If the application wants to hardwire the specific name of the header(s) it looks at, those names should be specific to the application (e.g. dataverse-id or something along those lines). But more generally, the name(s) should simply be provided to the application by a configuration setting.

The most appropriate thing to do, of course, is just read REMOTE_USER, though that is a problem on IIS. A fallback is to support a very standard sort of setting: a comma-delimited list of names, with REMOTE_USER handled specially in that list. Then you walk the list and take the first value you see from it. That handles essentially any case imaginable with a trivial amount of work.

> p.s. In developing Shibboleth support for Dataverse as an SP have been
> heavily influenced by the attributes sent by the IdP at
> http://www.testshib.org . I basically took a look at
> https://demo.dataverse.org/Shibboleth.sso/Session (output below) as a
> starting point for what attributes are reasonable to expect from an IdP:

That explains where you went a bit off-track. Those are not attributes "from an IdP", those are attributes after they've been mapped into local header names by the SP. There is no way to know apriori what actual data might be in them.

The attributes from the IdP have totally different names that are highly standardized, and could in theory be anything. But asking somebody to artificially map a standard attribute containing an email address into a header named "eppn" is just a recipe for confusion, as I said.

(I'm saying all this on the assumption that Dataverse is an application people are deploying locally. For a cloud service, the SAML interface would be defined solely in terms of the standard SAML Attribute name(s) it supports.)

-- Scott