[ 
https://jira.duraspace.org/browse/DS-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Masár updated DS-994:
--------------------------

    Fix Version/s:     (was: 3.0)
                   4.0
           Labels: has-patch  (was: )
    
> Add allow/deny rules for self-registration in the simple password 
> authentication module
> ---------------------------------------------------------------------------------------
>
>                 Key: DS-994
>                 URL: https://jira.duraspace.org/browse/DS-994
>             Project: DSpace
>          Issue Type: Improvement
>            Reporter: Hardy Pottinger
>            Assignee: Hardy Pottinger
>              Labels: has-patch
>             Fix For: 4.0
>
>         Attachments: 
> DS-994-force-canselfregister-to-always-return-false.patch, 
> DS-994-warning-patch-is-missing-required-changes-to-dspace-cfg.patch
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> The simple authentication module currently has a method where you can 
> selectively allow self-registration for certain domains. If one wishes to use 
> simple password authentication and self-registration as part of a stack of 
> authentication modules, it is important to limit self-registration to only 
> domains that cannot use an alternate authentication method (in particular, 
> Shibboleth), or competing eperson records with the same email address can 
> break authorization rules (in plain English, some folks won't be able to get 
> to stuff they should be able to get to).
> Clarification: the problem is not actually in duplicate e-mail addresses in 
> the system, as that's not possible given the table schema, duplicates would 
> cause an SQL exception. The problem is the automatically-created 
> authorizations, which result from a shibboleth login (special groups logic, 
> we've got a customized version of the shib authentication module, which 
> assigns people to certain groups--think 'campus'--based on their e-mail 
> address). None of those group memberships are created if an existing eperson 
> record is found. The net result is, people who have self-registered are never 
> allowed access to things they should have access to (in our system, the 
> problem is usually with ETDs, as they can have
> specific access permissions set, at the request of the authors: campus access 
> only, or System-wide access).
> Simply put, if an individual can authenticate with Shib then you want to 
> ensure that they do so in order that they get assigned to the correct groups. 
> And the only way to do that is to turn off self-registration for certain 
> e-mail domains.
> This is a work in progress, I should be able to post a patch of the work so 
> far later today.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel

Reply via email to