[
https://jira.duraspace.org/browse/DS-937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24061#comment-24061
]
Mark Diggory commented on DS-937:
---------------------------------
I'd first stick to something that can be supported in DSpace and not dependent
on any external naming services. you can eventually expose the identifiers
through external naming services if you choose... DOI/Handle/etc...
the UUID are meant to be stored very close to the record and be unique for the
record. This means they should eventually replace the internal int eperson_id.
I would add do the following:
1.) add uuid column to eperson table.
2.) generate random new UUID for all EPersons in the system
3.) adjust fkey constraints and table to use uuid as key
additional activities:
4.) treat eperson table as "profile" migrate password and username data to new
table eperson_password
5.) create separate table for eperson_shibboleth and eperson_ldap to allow
separate configuration of these identifier mappings. (similar approaches for
CAS and other authentication systems maybe even openId/facebook/etc).
6.) link authenticator capabilities explicitly to the above tables, new
authenticators may provide additional tables when necessary.
eventually....
7.) process items and replace email address metadata in provenance field with
eperson uuid (or explore additional project to move this out of Item and into a
separate history system.
> Stop using Email Address as Identifier for DSpace User.
> -------------------------------------------------------
>
> Key: DS-937
> URL: https://jira.duraspace.org/browse/DS-937
> Project: DSpace
> Issue Type: Improvement
> Components: DSpace API
> Affects Versions: 1.5.0, 1.5.1, 1.5.2, 1.6.0, 1.6.1, 1.6.2, 1.7.0, 1.7.1,
> 1.7.2, 1.8.0
> Reporter: Mark Diggory
> Priority: Major
>
> Use of email address as a persistent identifier for the DSpace conflicts with
> the fact that email addresses are not persistent. Email addresses go away
> and/or are reassigned to other individuals. There are also policy concerns
> with Authenticators like Shibboleth and CAS that may or may not deliver an
> email address as a organizational policy.
> This Task is a placeholder to identify a solution to correct for the problem.
> 1.) DSpace should use a different identifier / key for the EPerson (netid? or
> combination of "authenticator + netID")
> 2.) DSpace should make providing an email address as optional for cases where
> the Authentication features lack this specific capability.
> 3.) Issuing emails should be optional for accounts without email addresses.
> 4.) Stop storing email address (or any other detail about who made the
> change) in dc.description.provenance field.
> One proposed solution to this problem is that the Authentication Method
> should be broken off of EPerson and stored separately, making EPerson a
> "Profile" and the method of Authentication be stored separately (Password,
> Certificate, LDAP, Shibboleth, CAS, Facebook, Google) Different
> AuthenticationMethods may store the data as they see fit. And the Profile
> would store only those local details for that user.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.duraspace.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
