[Dspace-tech] DSpace Account Management
Hello, All~ I am working on a proposal about DSpace account management for the /UCIspace @ the Libraries/ system. As with other DSpace instances, we restrict access to some bitstreams, and require interested users to submit an application for access. From what I can tell, there are two steps to providing access: registration (either by the user or an admin), then an administrator adds them to the access group. What I'm wondering is how do others handle this, both from a user and admin perspective? Thanks in advance for any input! ~Caryn ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Caryn Neiswender Digital Projects Specialist UC Irvine Libraries (949) 824-9086 Curiosity sends us out To a world both larger and smaller Than what we know and believe in With a passion for finding an answer Or at least understanding our questions. -Excerpt from Julia Alvarez's Why I Am in Love with Librarians. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] DSpace Account Management
On Fri, Mar 12, 2010 at 11:19 AM, Caryn Neiswender cary...@uci.edu wrote: Hello, All~ I am working on a proposal about DSpace account management for the UCIspace @ the Libraries system. As with other DSpace instances, we restrict access to some bitstreams, and require interested users to submit an application for access. From what I can tell, there are two steps to providing access: registration (either by the user or an admin), then an administrator adds them to the access group. What I'm wondering is how do others handle this, both from a user and admin perspective? Mostly manually, which is a major pain-point for us. We (as a multi-institutional repository) do have some magic hackery under the hood that reads IPs and temporarily assigns sessions to a group based on associating IP addresses with a given campus. We also have some LDAP hackery that assigns sessions to an affiliation group, again based on campus affiliation proven through a central LDAP login system. I had thoughts once of using the ad-hoc affiliation groups to create a catch-all collection for each individual campus, so that people who log in for the first time expecting to be able to deposit can do so at once, even if I have to move their first few deposits and change their privileges later on. That idea didn't get any traction, unfortunately. What we can't do that I would very much like us to: - automagically populate the eperson directory based on LDAP login results and lookups (you logged in? congrats, you're an eperson! an admin looked you up? congrats, you're an eperson!) - assign people to a group based on being in a given department or research unit - assign people to a group based on being in a specific course (and revoke their access when the course is over) - assign people to a group based on program/degree status (ETDs!) Obviously this is not entirely DSpace's fault; our LDAP can't actually give us a lot of this information. We are taking baby steps with Shibboleth and course-management-system authentication in other library contexts that may eventually help with some of these challenges. For the time being, though, all I can do is be as speedy as I can about adding people to groups manually. Definitely not ideal. Dorothea -- Dorothea Salods...@library.wisc.edu Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] DSpace Account Management
Caryn, Have you seen the Request Copy add-on? It may have some of the functionality you are looking for, but the version that currently exists does -not- work with DSpace 1.5. In fact, it doesn't work with 1.4, either. The developers, from what I have learned, are no longer supporting it. http://dspace.org/add-ons-and-extensions/#request We have hacked together an updated version of this to allow us to upgrade to 1.5, but I'm pretty sure it's not the right way to do it in DSpace's new development environment. --Joel Joel Richard IT Specialist, Web Services Department Smithsonian Institution Libraries | http://www.sil.si.edu/ (202) 633-1706 | (202) 786-2861 (f) | richar...@si.edu From: Caryn Neiswender cary...@uci.edu Date: Fri, 12 Mar 2010 12:19:24 -0500 To: dspace-tech@lists.sourceforge.net dspace-tech@lists.sourceforge.net Subject: [Dspace-tech] DSpace Account Management Hello, All~ I am working on a proposal about DSpace account management for the UCIspace @ the Libraries system. As with other DSpace instances, we restrict access to some bitstreams, and require interested users to submit an application for access. From what I can tell, there are two steps to providing access: registration (either by the user or an admin), then an administrator adds them to the access group. What I'm wondering is how do others handle this, both from a user and admin perspective? Thanks in advance for any input! ~Caryn ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Caryn Neiswender Digital Projects Specialist UC Irvine Libraries (949) 824-9086 Curiosity sends us out To a world both larger and smaller Than what we know and believe in With a passion for finding an answer Or at least understanding our questions. -Excerpt from Julia Alvarez's Why I Am in Love with Librarians. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] DSpace Account Management
Hi, Dorothea~ The ideal solution you describe would be very nice! We have experienced similar issues with hooking our LDAP up to DSpace. This is something we have on our docket for future development. At the moment, some of our authorized users are actually not from our LDAP, so we will need to develop a stacked method. One solution I've envisioned goes something like this: 1. User completed some sort of webform based on the community or collection (not all will have the same application, unfortunately). 2. Responses are sent to a new db table, which populates an admin queue. 3. Admin reviews the application and clicks accept/reject, and adds an expiration date (this data also populates a second new db table). 4. Data is then passed to eperson and epersongroup2eperson table. This is possibly ambitious, but I think it would do what we need it to do... ~Caryn Original Message Subject: Re: [Dspace-tech] DSpace Account Management From: Dorothea Salo dorothea.s...@gmail.com To: Dspace Tech DSpace-tech@lists.sourceforge.net Date: 3/12/2010 9:38 AM On Fri, Mar 12, 2010 at 11:19 AM, Caryn Neiswender cary...@uci.edu wrote: Hello, All~ I am working on a proposal about DSpace account management for the UCIspace @ the Libraries system. As with other DSpace instances, we restrict access to some bitstreams, and require interested users to submit an application for access. From what I can tell, there are two steps to providing access: registration (either by the user or an admin), then an administrator adds them to the access group. What I'm wondering is how do others handle this, both from a user and admin perspective? Mostly manually, which is a major pain-point for us. We (as a multi-institutional repository) do have some magic hackery under the hood that reads IPs and temporarily assigns sessions to a group based on associating IP addresses with a given campus. We also have some LDAP hackery that assigns sessions to an affiliation group, again based on campus affiliation proven through a central LDAP login system. I had thoughts once of using the ad-hoc affiliation groups to create a catch-all collection for each individual campus, so that people who log in for the first time expecting to be able to deposit can do so at once, even if I have to move their first few deposits and change their privileges later on. That idea didn't get any traction, unfortunately. What we can't do that I would very much like us to: - automagically populate the eperson directory based on LDAP login results and lookups (you logged in? congrats, you're an eperson! an admin looked you up? congrats, you're an eperson!) - assign people to a group based on being in a given department or research unit - assign people to a group based on being in a specific course (and revoke their access when the course is over) - assign people to a group based on program/degree status (ETDs!) Obviously this is not entirely DSpace's fault; our LDAP can't actually give us a lot of this information. We are taking baby steps with Shibboleth and course-management-system authentication in other library contexts that may eventually help with some of these challenges. For the time being, though, all I can do is be as speedy as I can about adding people to groups manually. Definitely not ideal. Dorothea -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] DSpace Account Management
Hi, Joel~ Thanks! I actually have seen this add-on. We have a tricky situation here in that the collections in the community (access is granted on the community level) have more than 1,000 items... Also, part of our technical design needs to include a customized form, based on community (not all community admins want to request the same information from potential users). We're definitely looking for a very robust and complex system - at least that's our ideal... ~Caryn Original Message Subject: Re: [Dspace-tech] DSpace Account Management From: Richard, Joel M richar...@si.edu To: Caryn Neiswender cary...@uci.edu, dspace-tech@lists.sourceforge.net dspace-tech@lists.sourceforge.net Date: 3/12/2010 9:40 AM Caryn, Have you seen the Request Copy add-on? It may have some of the functionality you are looking for, but the version that currently exists does -not- work with DSpace 1.5. In fact, it doesn't work with 1.4, either. The developers, from what I have learned, are no longer supporting it. http://dspace.org/add-ons-and-extensions/#request We have hacked together an updated version of this to allow us to upgrade to 1.5, but I'm pretty sure it's not the right way to do it in DSpace's new development environment. --Joel Joel Richard IT Specialist, Web Services Department Smithsonian Institution Libraries | http://www.sil.si.edu/ (202) 633-1706 | (202) 786-2861 (f) | richar...@si.edu From: Caryn Neiswender cary...@uci.edu Date: Fri, 12 Mar 2010 12:19:24 -0500 To: dspace-tech@lists.sourceforge.net dspace-tech@lists.sourceforge.net Subject: [Dspace-tech] DSpace Account Management Hello, All~ I am working on a proposal about DSpace account management for the UCIspace @ the Libraries system. As with other DSpace instances, we restrict access to some bitstreams, and require interested users to submit an application for access. From what I can tell, there are two steps to providing access: registration (either by the user or an admin), then an administrator adds them to the access group. What I'm wondering is how do others handle this, both from a user and admin perspective? Thanks in advance for any input! ~Caryn ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Caryn Neiswender Digital Projects Specialist UC Irvine Libraries (949) 824-9086 Curiosity sends us out To a world both larger and smaller Than what we know and believe in With a passion for finding an answer Or at least understanding our questions. -Excerpt from Julia Alvarez's Why I Am in Love with Librarians. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] DSpace Account Management
That would actually be pretty fantastic, because right now the trajectory for getting deposit rights is very confusing for our users. (I logged in to mi...@uw! Why can't I put my stuff somewhere? Why don't I have a collection? Wait, I have to email somebody for that?! Bah, I'll just go use Drupal.) The only thing I would add is some way for this process to include a request for a new community/collection. Dorothea On Fri, Mar 12, 2010 at 12:12 PM, Caryn Neiswender cary...@uci.edu wrote: Hi, Dorothea~ The ideal solution you describe would be very nice! We have experienced similar issues with hooking our LDAP up to DSpace. This is something we have on our docket for future development. At the moment, some of our authorized users are actually not from our LDAP, so we will need to develop a stacked method. One solution I've envisioned goes something like this: 1. User completed some sort of webform based on the community or collection (not all will have the same application, unfortunately). 2. Responses are sent to a new db table, which populates an admin queue. 3. Admin reviews the application and clicks accept/reject, and adds an expiration date (this data also populates a second new db table). 4. Data is then passed to eperson and epersongroup2eperson table. This is possibly ambitious, but I think it would do what we need it to do... ~Caryn Original Message Subject: Re: [Dspace-tech] DSpace Account Management From: Dorothea Salo dorothea.s...@gmail.com To: Dspace Tech DSpace-tech@lists.sourceforge.net Date: 3/12/2010 9:38 AM On Fri, Mar 12, 2010 at 11:19 AM, Caryn Neiswender cary...@uci.edu wrote: Hello, All~ I am working on a proposal about DSpace account management for the UCIspace @ the Libraries system. As with other DSpace instances, we restrict access to some bitstreams, and require interested users to submit an application for access. From what I can tell, there are two steps to providing access: registration (either by the user or an admin), then an administrator adds them to the access group. What I'm wondering is how do others handle this, both from a user and admin perspective? Mostly manually, which is a major pain-point for us. We (as a multi-institutional repository) do have some magic hackery under the hood that reads IPs and temporarily assigns sessions to a group based on associating IP addresses with a given campus. We also have some LDAP hackery that assigns sessions to an affiliation group, again based on campus affiliation proven through a central LDAP login system. I had thoughts once of using the ad-hoc affiliation groups to create a catch-all collection for each individual campus, so that people who log in for the first time expecting to be able to deposit can do so at once, even if I have to move their first few deposits and change their privileges later on. That idea didn't get any traction, unfortunately. What we can't do that I would very much like us to: - automagically populate the eperson directory based on LDAP login results and lookups (you logged in? congrats, you're an eperson! an admin looked you up? congrats, you're an eperson!) - assign people to a group based on being in a given department or research unit - assign people to a group based on being in a specific course (and revoke their access when the course is over) - assign people to a group based on program/degree status (ETDs!) Obviously this is not entirely DSpace's fault; our LDAP can't actually give us a lot of this information. We are taking baby steps with Shibboleth and course-management-system authentication in other library contexts that may eventually help with some of these challenges. For the time being, though, all I can do is be as speedy as I can about adding people to groups manually. Definitely not ideal. Dorothea -- Dorothea Salods...@library.wisc.edu Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] DSpace Account Management
The first feature Tim lists comes built-in to DSpace already, no? You can do LDAP lookup and add then add them to a special group on the fly. The second feature seems similarly possible as as long as you can pull the necessary attributes from your directory. Jason -- Jason Stirnaman Biomedical Librarian, Digital Projects A.R. Dykes Library, University of Kansas Medical Center jstirna...@kumc.edu 913-588-7319 On 3/12/2010 at 12:29 PM, in message 4b9a881a.4090...@duraspace.org, Tim Donohue tdono...@duraspace.org wrote: Hi all, To add to Dorothea's response for an ideal way to manage accounts. When I was at U of Illinois at Urbana-Champaign (UIUC), we implemented a similar auto-account management solution using our local LDAP directory (and local Active Directory groups). I unfortunately never got around to fully sharing it as it was still semi-UIUC specific. As Dorothea implies, every LDAP is unfortunately different, and not all LDAPs store this information (and if they do, they may store it in different fields or use different values/codes in those fields). However, perhaps the UIUC code could be minimally made available for others to improve and make more configurable for a generic institution -- it's at least a potential starting point. I've noted what general features we had implemented at UIUC below, based on Dorothea's wishlist: On 3/12/2010 11:38 AM, Dorothea Salo wrote: What we can't do that I would very much like us to: - automagically populate the eperson directory based on LDAP login results and lookups (you logged in? congrats, you're an eperson! an admin looked you up? congrats, you're an eperson!) We had this feature implemented at Illinois -- if you could login (via a custom UIUC login solution) we'd know your NetID and auto-create an EPerson by doing an LDAP lookup to get your Name. We'd also then auto-add you to an UIUC Users group in our DSpace -- which gave some immediate access rights to you (including the immediate ability to submit to a generic UIUC Research Collection). - assign people to a group based on being in a given department or research unit We could also basically do this. We'd look up your Department name in LDAP, and if we could *find* a DSpace Group of that name, then we'd auto-add you to it for the remainder of your session. However if no DSpace Group existed with that name, then nothing happened. - assign people to a group based on being in a specific course (and revoke their access when the course is over) Sorry, we didn't have specific course info in our LDAP -- so this wasn't possible for us at UIUC. - assign people to a group based on program/degree status (ETDs!) We also had a basic implementation for this. Based on your degree *code* in LDAP (we had to contact our local IT depart to figure out the meaning of various codes in our LDAP fields), we could add you automatically to a UIUC Masters Students or UIUC UnderGrad Students, UIUC PhD Students or UIUC Faculty/Staff group in DSpace. Again, much of this code I built while at UIUC was a bit UIUC-specific (though there were some configurable parts would could allow it to work for UIUC-similar LDAP directories). I had always wanted to make it more widely available but unfortunately never got around to it. But, hopefully, assuming my UIUC colleagues agree to it, we could get a copy of what was created into JIRA for someone to build from. So, I don't have a complete answer to the problem -- but a possible contact to help someone come up with an answer that will work for at least those institutions who use LDAP. But, obviously, we need to find a volunteer developer to help bring this forward! - Tim -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] DSpace Account Management
Hi Jason, You are correct. I forgot we now have the following in the dspace.cfg: webui.ldap.autoregister = true If you configure DSpace LDAP authentication (using the ldap.* configs), then it will auto-register someone as an EPerson based on their LDAP info. The big difference with what we built at UIUC was that we were *not* using LDAP Authentication (authentication occurred in another system via NetID), we just looked up a person's name via LDAP after a successful authentication. As for the assign people to a group based on being in a given department or research unit feature. You are correct that it would be possible in a similar method to what is already in DSpace. But, it would just take someone to implement it, and add appropriate configurations to dspace.cfg - Tim On 3/12/2010 12:47 PM, Jason Stirnaman wrote: The first feature Tim lists comes built-in to DSpace already, no? You can do LDAP lookup and add then add them to a special group on the fly. The second feature seems similarly possible as as long as you can pull the necessary attributes from your directory. Jason -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] DSpace Account Management
On Fri, Mar 12, 2010 at 11:38:35AM -0600, Dorothea Salo wrote:
What we can't do that I would very much like us to:
- automagically populate the eperson directory based on LDAP login
results and lookups (you logged in? congrats, you're an eperson! an
admin looked you up? congrats, you're an eperson!)
I thought it already did that. (webui.ldap.autoregister) Yes, when
enabled it will set the EPerson's email, given name, surname, and
phone from the LDAP response if they were present. Mmmm, well, it
does when you log in, but maybe not if the admin created your record
-- that would be helpful.
But I also think that's wrong-way-round. Instead, DSpace should just
remember whence came the original authentication which allowed the
creation of an EPerson. Local: store other user data locally. LDAP:
go out to the directory whenever an EPerson attribute is wanted (with
a cache, perhaps).
All we need to know, to attribute a session to an EPerson, is that
authentication of a certain net-id succeeded. All we need to know, to
fulfil a subscription, is how to get a given EPerson's current email
address. I think that anything about an EPerson which DSpace doesn't
have to store, DSpace should not store.
[decorate sessions with groups based on various criteria that the
directory should provide]
A fairly general way to map LDAP_group-DSpace_group at logon would
help, if the data are in the directory.
Obviously this is not entirely DSpace's fault; our LDAP can't actually
give us a lot of this information.
I hear you. We face similar problems here. :-{ We complain for a
decade and things finally move a little.
--
Mark H. Wood, Lead System Programmer mw...@iupui.edu
Friends don't let friends publish revisable-form documents.
pgpVR2A0wnBTs.pgp
Description: PGP signature
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
