Hi Phil, all,

Very interesting issue (we discussed this before of course, in IRC).

The Dutch Dataverse Network (DDN) has one IdP, SURFconext, that proxies
SAML messages to and from university IdPs and SPs. From the
documentation about SURFconext I see the same possible user identifiers,
although not all source IdPs necessarily use all attributes or even the
same subset. NameID appears to always be present (I see it in the logs),
and we seem to ignore the ePPN.

I'll have to discuss with our team what kind of mapping of attributes we
do exactly. I imagine Shibboleth could be configured to map the best
available ID to a certain attribute that Dataverse expects?

Ben

Philip Durbin schreef op 05-02-15 om 16:45:

> Happy New Year, dvn-auth list! :)
>
> I just created a ticket about eppn vs. ePTID vs. NameID at
> https://github.com/IQSS/dataverse/issues/1422
>
> Comments there or here are certainly welcome!
>
> Phil
>
> On Wed, Jul 30, 2014 at 1:39 PM, Philip Durbin
> <philip_durbin@harvard.edu> wrote:
>> Hi Leonhard!
>>
>> Thanks for your reply! I'm very curious what your Shibboleth
>> federation hotline has to say.
>>
>> Meanwhile, a little bird on this list pointed me to a "Cloud Services
>> Cookbook" recorded only a couple weeks ago that seems to have a ton of
>> related advice: http://www.incommon.org/iamonline/
>>
>> I'll copy the DO and DON'T bullet points from the slides and in our
>> heads we can all translate "Vendor" to "Dataverse" and "Campus" to all
>> the IdP providers out there:
>>
>> http://www.incommon.org/docs/iamonline/20140716_IAMOnline.pdf
>>
>>
>> Slide 11
>> Challenges: Network IDs and Email Addresses
>>
>> CONSIDER the relationship between ePPN and mail.
>>
>> Campus: DO socialize the use of organizational email addresses.
>>
>> Campus: DO make eduPersonPrincipalName useful.
>>
>> Vendor: DO be cautious about using mail as a unique identifier
>>
>>
>> Slide 12
>> Challenges: Scoped and Unscoped Identifiers
>>
>> Campus: DO work with service providers to understand how data is being
>> interpreted.
>>
>> Vendor: DON'T assume that a simple username is unique across domains
>> and subdomains.
>>
>>
>> Slide 19
>> Challenge: Usernames Change
>>
>> “What's in a name? ...a rose by any other name would smell as sweet"
>> -‐Act II, Scene II. Romeo and Juliet
>>
>> Vendor: DO be prepared for username changes.
>>
>> Campus: DO standardize internally on a stable "serial number" for users.
>>
>> Campus: DO support a varied set of identifiers.
>>
>> DON'T be afraid of eduPersonTargetedID.
>>
>> The last slide links to
>> https://carmenwiki.osu.edu/display/CICIDM/Current+Working+Draft+of+Cloud+Services+Cookbook#CurrentWorkingDraftofCloudServicesCookbook-Identifiers
>> which seems to have similar advice but not in bullet form. :) Much
>> more detail, I mean.
>>
>> So! My takeaway from all this is that I would very much like the IdPs
>> to send Dataverse a "stable 'serial number' for users". That's the
>> thing I want to store in the database on the Dataverse side. Can all
>> the IdPs out there send me this?
>>
>> Phil
>>
>> On Wed, Jul 30, 2014 at 3:00 AM, Leonhard Maylein
>> <Maylein@ub.uni-heidelberg.de> wrote:
>>> Hi,
>>>
>>> I'm not really a shibboleth expert. As far as I can see,
>>> ePTID is used mainly in Shibboleth 1.x/SAML 1.x.
>>> Shibboleth 2.x uses the persistentNameID (see
>>> https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPTargetedID)
>>>
>>> Shibboleth 1.x is no longer supported (see
>>> https://wiki.shibboleth.net/confluence/display/SHIB/WebHome).
>>>
>>> From a data privacy point of view, eppn could be problematic.
>>> PersistentNameIDs are pseudonyms.
>>> But I'm not sure if every IdP supports the persitentNameID,
>>> although there are a lot of service providers (especially publishers)
>>> which use this ID for personalization).
>>>
>>> Maybe you could make it configurable which attribute/id is used?
>>>
>>> To be sure, I will forward your email to our shibboleth federation
>>> hotline.
>>>
>>> Leonhard Maylein
>>>
>>>
>>>
>>> Am 29.07.2014 um 23:15 schrieb Philip Durbin:
>>>> Hello!
>>>>
>>>> Question for all you Shibboleth experts out there... If I'd like to
>>>> take one of the attributes and store in in Dataverse as a persistent
>>>> identifier? Which one should I use?
>>>>
>>>>  From playing around with the IdP at http://testshib.org I assumed
>>>> "persistent-id" would be the one to use. It looks nice and unique:
>>>>
>>>> persistent-id:
>>>> https://idp.testshib.org/idp/shibboleth!https://apitest.dataverse.org/shibboleth!iGc07gHi6Wv0UM8djmFZrTjTDY0=
>>>>
>>>> However! I'm hearing that "persistent-id" may not be so commonly
>>>> used... that perhaps in Higher Ed anyway "eppn" might be used instead.
>>>> The weird thing to me about "eppn", however is that (at least from
>>>> TestShib) there's a username in it:
>>>>
>>>> eppn: myself@testshib.org
>>>>
>>>> Furthermore, eppn is allowed to change (!) according to
>>>>
>>>> https://www.internet2.edu/media/medialibrary/2013/09/04/internet2-mace-dir-eduperson-201203.html#eduPersonPrincipalName
>>>>
>>>> "Values of eduPersonPrincipalName are often, but not required to be,
>>>> human-friendly, and may change as a result of various business
>>>> processes. They may also be reassigned after a locally-defined period
>>>> of dormancy. Applications that require a guarantee of non-reassignment
>>>> and more stability, but can tolerate values unfriendly (and unknown)
>>>> to humans should refer to the eduPersonTargetedID attribute."
>>>>
>>>> So... maybe we should require eduPersonTargetedID (also known as
>>>> ePTID) instead...
>>>>
>>>> But then I checked in with a non-Higher Ed person, and he uses
>>>> Assertion -> Subject -> NameID. It looks like this:
>>>>
>>>> <saml2:NameID
>>>> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">user1</saml2:NameID>
>>>>
>>>> It's got "persistent" in it, which I like. :)
>>>>
>>>>  From what I can tell from docs above "[ePTID] is an abstracted version
>>>> of [NameID]" anyway, so maybe I should just require NameID so
>>>> non-Higher Ed people aren't confused.
>>>>
>>>> Of course, I may just be confusing myself... I hope it's clear what
>>>> I'm asking... What we need on the Dataverse side is to but something
>>>> in the "FIXME" below:
>>>>
>>>> permanentId = httpServletRequest.getAttribute("FIXME");
>>>>
>>>> Should the "FIXME" be "NameID" perhaps? "eppn"? Something else? Please
>>>> advise.
>>>>
>>>> We'll be using this value to find the Shib users in the system each
>>>> time they log in.
>>>>
>>>> Thanks!
>>>>
>>>> Phil
>>>>
>>>> p.s. Chats I just had (summarized above):
>>>>
>>>> http://irclog.perlgeek.de/shibboleth/2014-07-29
>>>>
>>>> Time  Nick    Message
>>>> 19:57 pdurbin hsnopi or rkeene do you use "persistent-id" for anything?
>>>>
>>>> 19:59 hsnopi  not taht I am specifically aware of. I think it is used
>>>> to give a user a permenant id but i could be very very wrong
>>>>
>>>> 19:59 pdurbin that's how I was thinking I'd use it
>>>>
>>>> 19:59 pdurbin but I'm also hearing that eppn is preferred, maybe?
>>>>
>>>> 20:00 pdurbin the IdP at http://testshib.org sends both
>>>>
>>>> 20:00 hsnopi  that is so far out of my league
>>>>
>>>> 20:00 pdurbin eppn: myself@testshib.org
>>>>
>>>> 20:00 pdurbin persistent-id:
>>>>
>>>> https://idp.testshib.org/idp/shibboleth!https://apitest.dataverse.org/shibboleth!iGc07gHi6Wv0UM8djmFZrTjTDY0=
>>>>
>>>> 20:01 pdurbin persistent-id seemed "safer" to use... more unique...
>>>>
>>>> 20:01 hsnopi  i seem to vaguely recall something about eppn going away
>>>> at soem point.
>>>>
>>>> 20:01 pdurbin hmm
>>>>
>>>>
>>>>
>>>> http://www.evanchooly.com/logs/%2523glassfish/2014-07-29
>>>>
>>>> pdurbin whartung: persistent-id or eppn?
>>>>
>>>> whartung pdurbin: eh?
>>>>
>>>> pdurbin heh
>>>>
>>>> pdurbin whartung: http://irclog.perlgeek.de/shibboleth/2014-07-29
>>>>
>>>> whartung frankly, I don't recognize either of those :)
>>>>
>>>> pdurbin whartung: what attribute do you use to uniquely identify a
>>>> user who has logged in via shibboleth?
>>>>
>>>> whartung Subject->NAmeID
>>>>
>>>> pdurbin huh
>>>>
>>>> pdurbin I'm not used to seeing "->" in an attribute
>>>>
>>>> whartung Assertion -> Subject -> NameID
>>>>
>>>> pdurbin oh oh
>>>>
>>>> whartung no, it's the heirarchy
>>>>
>>>> pdurbin whartung: you're giving me the xpath ;)
>>>>
>>>> whartung yea
>>>>
>>>> pdurbin cool. thanks
>>>>
>>>> pdurbin NameID. hmm
>>>>
>>>> pdurbin commonly used?
>>>>
>>>> whartung Apparently
>>>>
>>>> pdurbin ok. eppn comes from higher ed. eduPersonPrincipalName
>>>> https://www.incommon.org/federation/attributesummary.html
>>>>
>>>> whartung ok
>>>>
>>>> whartung yea, we're not in that domain
>>>>
>>>> whartung generic Response of ours:
>>>> http://pastie.org/private/oay0trwmvrw9e0haekqmlw
>>>>
>>>> pdurbin ok so <saml2:NameID
>>>>
>>>> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">kayyagari</saml2:NameID>
>>>>
>>>> pdurbin interesting
>>>>
>>>> whartung right
>>>>
>>>> pdurbin so I'm seeing "persistent" there and under "longevity" at
>>>> https://wiki.shibboleth.net/confluence/display/SHIB2/NameIDAttributes
>>>>
>>>> pdurbin "persistent: identifiers which are good for a long period of
>>>> time (e.g. years) but which the IdP may revoke"
>>>>
>>>> whartung yea, perahps we should use "permanent" instead
>>>>
>>>> pdurbin right
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> dvn-auth mailing list
>>>> dvn-auth@lists.iq.harvard.edu
>>>>
>>>> To unsubscribe from this list or get other information:
>>>>
>>>> https://lists.iq.harvard.edu/mailman/listinfo/dvn-auth
>>>>
>>>
>>>
>>> _______________________________________________
>>> dvn-auth mailing list
>>> dvn-auth@lists.iq.harvard.edu
>>>
>>> To unsubscribe from this list or get other information:
>>>
>>> https://lists.iq.harvard.edu/mailman/listinfo/dvn-auth
>>>
>>
>>
>> --
>> Philip Durbin
>> Software Developer for http://dataverse.org
>> http://www.iq.harvard.edu/people/philip-durbin
>
>
> --
> Philip Durbin
> Software Developer for http://dataverse.org
> http://www.iq.harvard.edu/people/philip-durbin
> _______________________________________________
> dvn-auth mailing list
> dvn-auth@lists.iq.harvard.edu
>
> To unsubscribe from this list or get other information:
>
> https://lists.iq.harvard.edu/mailman/listinfo/dvn-auth