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/shibb…
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(a)testshib.org
Furthermore, eppn is allowed to change (!) according to
https://www.internet2.edu/media/medialibrary/2013/09/04/internet2-mace-dir-…
"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(a)testshib.org
20:00 pdurbin persistent-id:
https://idp.testshib.org/idp/shibboleth!https://apitest.dataverse.org/shibb…
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
--
Philip Durbin
Software Developer for http://dataverse.orghttp://www.iq.harvard.edu/people/philip-durbin
I'd like to share with both the dvn-auth list and the larger Google
Group a new "pluggable authentication" design we have come up with for
Dataverse 4.0.
We've tried to incorporate as much feedback as we could in the design
but could use your help in reviewing it to make sure we haven't missed
anything:
https://github.com/IQSS/dataverse/blob/master/doc/Architecture/auth.md
At a high level, we hear you loud and clear that you want Shibboleth
support. Some groups seem interested in contributing code for LDAP and
OAuth. We plan to continue to support IP groups. We'd like to
introduce API keys.
We're not picky about how you give us feedback on the pluggable auth
design. You can comment directly on the commits on GitHub. Or reply to
this email. Or hit us up on IRC.
We'd like to start coding this up soon. :)
Thanks!
Phil
--
Philip Durbin
Software Developer for http://dataverse.orghttp://www.iq.harvard.edu/people/philip-durbin
Hi Ben,
Thanks! Obviously, this is a lot for anyone to digest so as we've discussed
at http://irclog.iq.harvard.edu/dataverse/2014-07-10 we've pasted it into a
Google Doc at
https://docs.google.com/document/d/1JMGPtwS7gcKFNaCDIKXSea1p8iWpS7BzpwRNQsc…
for people to comment on specific points.
I'm also going to cc the dvn-auth list so we don't miss anybody.
People are welcome to discuss these ideas in this very thread too, of
course. I just think the Google Doc will help focus the conversation. :)
Phil
On Thu, Jul 10, 2014 at 9:28 AM, Ben Companjen <ben.companjen(a)dans.knaw.nl>
wrote:
> Hi IQSS, all,
>
> I'm looking at the future of the Dutch Dataverse Network, which will at
> some point move to Dataverse 4, and I'm trying to find out how our current
> model and procedures of distributed user and role management (should) map
> to Dataverse 4.
>
> Philip has pointed out the user model (which is not final) at
> https://raw.githubusercontent.com/IQSS/dataverse/master/doc/Architecture/Us…,
> but this class diagram is only one view of the system and I could not be
> sure that my ideas would fit.
>
>
> So, let me get to the contents of my actual message: a bit of background,
> an outline of handling access to dataverses in the current situation, use
> cases I am thinking of for the future (when we switch to v4), some related
> ideas and finally a few questions.
>
> Background:
>
> The Dutch Dataverse Network (DDN) is DANS providing Dataverse-as-a-service
> to universities and other research institutes, based on Dataverse (well,
> DVN) 3.6.2 with login and semi-automatic account creation via SAML. When
> the DDNaaS moved from the University of Utrecht to DANS, we implemented
> SAML using Shibboleth (fronting Glassfish with Apache) and centralised the
> network admin role at DANS, instead of having a network admin at every
> 'network participant'.
>
> For a longer introduction and link to the code on GitHub, let me refer to
> a thread on the dvn-auth list:
> https://lists.iq.harvard.edu/pipermail/dvn-auth/2014-April/000006.html
> (answer from Philip, my first introductory email is included but the
> original did not end up in the archives correctly) and
> https://lists.iq.harvard.edu/pipermail/dvn-auth/2014-July/000008.html
> (sent today about location of code).
>
>
> Current ways to manage dataverse creation and edit rights in DDN:
>
> - by default no-one gets creator/edit rights on account creation
> - university can decide to allow people to have a dataverse with admin
> role or access to dataverse with certain other role, because the university
> library has dataverse creator accounts
>
> Current ways of getting account with rights to certain dataverses in DDN:
>
> - first create account via federation
> 1. user logs in for the first time via federation
> 2. user creates an account
> 3. user asks:
> - library to get dataverse
> - dataverse admin to get access
> - first create account via Dataverse options -> Create User
> 1. dataverse admin / library creates 'normal' account with email address
> set to the address passed on successful login via the federation
> 2. dataverse admin / library gives user certain role(s)
> 3. user logs in via federation and has rights set
>
>
> Use cases for the future:
>
> - new users should get rights to certain lower-level dataverse(s) based on
> user's attributes that may or may not be included in SAML response; users
> need not wait for their access rights to be managed (i.e. go in, click "oh
> boy, I want my account" and start doing things without allowing them to
> create a mess). E.g.:
> - all students in a programme or course get read/dataset creation
> access to a programme/course dataverse
> - all faculty of a certain faculty get read and/or dataset creation
> access to a faculty dataverse
>
> - the network admin ("back office") only supports the university
> libraries/data librarians ("front office"); front office staff determines
> who needs access to what and supports users when necessary
> - the dataverse network has no access to LDAP servers or other services at
> universities ("clients") to query for user attributes that are not in the
> SAML response
> - a front office must have admin access to all dataverses at their
> university so that they can manage it after a researcher/student leaves
>
> Ideas relevant to the above use cases:
>
> - if real-time access to LDAP or similar services is unavailable, front
> offices could use lists of email addresses to pre-authorise certain rights
> to certain dataverses
> - the nested dataverse structure helps a lot in that a front office (as a
> dynamic group of staff users) are admin of top dataverses and thus have
> access to all sub-dataverses
> - a front office can be a (somewhat) dynamic group of users, whose group
> membership allows them to manage a top dataverse and dataverse inside that
> top dataverse, but the sub-dataverses do not belong to any one user in the
> front office group (currently all dataverses have a user as creator/owner,
> whose admin role cannot be changed. I deactivated the account of someone
> who had created five dataverses, but had left the institute, so that I
> didn't have to go into the database and change the ownership. The institute
> now uses a shared user account for administration purposes.)
>
> Questions:
>
> - Does/will Dataverse 4 support use cases like these?
> - Is my assumption in the second Idea correct?
> - Will I easily find out if I participate in the usability test?
> - Do you have any suggestions to do things differently with similar
> results?
> - Is anyone interested in discussing archimate views of Dataverse
> services? :)
>
> Well, thanks for getting to the end of this email. I'll be happy to
> provide any necessary clarification.
>
> Groeten,
>
> Ben
>
>
>
> Ben Companjen
>
> Information scientist / Information manager
>
> ben.companjen(a)dans.knaw.nl
>
> +31 6 1334 9717
>
> Skype: bencompanjen
>
>
> *Data Archiving and Networked Services (DANS)*
> DANS promotes sustained access to digital research data. See
> www.dans.knaw.nl for more information and contact details. DANS is an
> institute of KNAW and NWO.
>
>
> DANS | Anna van Saksenlaan 51 | 2593 HW The Hague | P.O. Box 93067 | 2509
> AB The Hague | +31 70 349 44 50 | info(a)dans.knaw.nl | www.dans.knaw.nl
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Dataverse Users Community" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dataverse-community+unsubscribe(a)googlegroups.com.
> To post to this group, send email to dataverse-community(a)googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dataverse-community/CFE461B6.30A95%25ben.…
> <https://groups.google.com/d/msgid/dataverse-community/CFE461B6.30A95%25ben.…>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
Philip Durbin
Software Developer for http://dataverse.org <http://thedata.org>
http://www.iq.harvard.edu/people/philip-durbin
Hi all,
As the future network admin of the Dutch Dataverse Network (DDN), I [0] am
currently involved with the transition of the service responsibility of
this service from the library of the University of Utrecht to Data
Archiving and Networked Services (an institute of the Royal Netherlands
Academy of Arts and Sciences and the Netherlands Organisation for
Scientific Research). My colleagues Eko Indarto and Arnoud Jippes are
working with me on this, as the developer and sysadmin respectively.
As Philip Durbin wrote in his email of October 3, 2013 [1], the DVN (v3.3)
was patched with OIOSAML to support federated login using personal
accounts supplied by Dutch higher educational institutions via SURFconext.
The patch is available and supports not only login, but account creation
with basic role assignment on first login based on SAML attributes as
well. It has worked for the current participating (and paying)
institutions, although the patch doesn't do session management very well.
After logging in for the first time, an account is created, but the user
needs to quit and restart the browser to be able to login for the first
time. This may also be why logging in when browsing studies takes the user
back to the homepage instead of the study that the user was looking at.
In this transition, we're upgrading the DVN software to 3.6.2, on a new
RHEL 6 with SELinux server. Next is to reconnect to SURFconext, the
federated login provider for Dutch higher education institutions. By May
1st the transition must be complete and it looks like we'll make it.
However, the "getting OIOSAML to work with 3.6.2" part has not been easy,
partly due to lack of experience with Glassfish and OIOSAML.
>From a system administration point of view, consolidation of deployment
environments continues to be important to us. Our Java applications are
deployed in Tomcat and use MySQL as DBMS with an Apache proxy in front of
Tomcat. This has also allowed us to use Shibboleth for federated login for
one of our other services, the long-term preservation archive EASY [2]. I
personally don't know the details, but setting up Shibboleth and the
connection to SURFconext has been harder than building software support
for Shibboleth, which I'm told boils down to getting attribute values from
environment variables. (We did need Shibboleth's lazy session mode
enabled.)
This environment and knowledge made us try patch the patch with Shibboleth
support. That includes fronting Glassfish with Apache. By the end of this
week I hope to know whether we succeeded :)
We (Eko, Arnoud and I) had a Skype call with Philip today, to exchange
some of our experiences with SAML and learn that DVN v4 will focus on
Shibboleth (because the demand was highest for Shibboleth). Support for
more generic authentication frameworks had crossed all our minds before,
but implementing such support is beyond any current plan (as I understood).
Although more a thought than a design, we suggested a plugin framework for
DVN to allow e.g. account creation/management as part of the login
procedure. With such a framework in place, we could create a plugin
instead of a patch that chooses a authentication provider, redirects to
the login page and performs the logic of assigning roles to new accounts
(i.e. authorisation) in between authentication and session start. One
plugin could be created for the Dutch environment, another for the US
environment (with InCommon) and perhaps yet another for Facebook
authentication.
We further asked about known DVN production environments in which DVN is
deployed in Tomcat and/or uses MySQL, but it appears that DVN relies on
some JavaEE features that Tomcat does not support. Perhaps TomEE might
help here, but Philip has no experience with this product. PostgreSQL
dependencies have been requested to be removed in DVN 4.
It was great to discuss DVN via Skype today, but we understand that
keeping the discussion open generally helps the wider community. We're
learning too, and would love to hear about experiences with environments
similar to ours, or different.
Regards,
Ben
[0]: http://dans.knaw.nl/en/content/ben-companjen (bencomp on Freenode,
@bencomp on Twitter)
[1]:
https://lists.iq.harvard.edu/pipermail/dvn-auth/2013-October/000001.html
[2]: https://easy.dans.knaw.nl/ui/home
Ben Companjen
Information scientist
ben.companjen(a)dans.knaw.nl
+31 6 1334 9717
Data Archiving and Networked Services (DANS)
DANS promotes sustained access to digital research data. See
<http://www.dans.knaw.nl/> for more information and contact details. DANS
is an institute of KNAW and NWO.
DANS | Anna van Saksenlaan 51 | 2593 HW The Hague | P.O. Box 93067 | 2509
AB The Hague | +31 70 349 44 50 | info(a)dans.knaw.nl | www.dans.knaw.nl
<http://www.dans.knaw.nl/>
