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 <[email protected]>
To: Dspace Tech <[email protected]>
Date: 3/12/2010 9:38 AM
On Fri, Mar 12, 2010 at 11:19 AM, Caryn Neiswender <[email protected]> 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® 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
