Details
-
Type:
Bug
-
Status: Closed (View Workflow)
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 5.6
-
Component/s: None
-
Environment:XMLUI (Mirage2 Theme)
CentOS Linux release 7.3.1611 (Core)
Tomcat 7
Apache/2.4.6 (CentOS)
-
Attachments:
-
Comments:13
-
Documentation Status:Not Required
Description
Hello,
we are trying to setup Shibboleth authentication together with Password authentication in our DSpace 5.6 installation. Both authentication methods are working (e.g. I can log in to DSpace using my institution account or using my local DSpace account). But during testing, I've encountered following problem:
Description
After successful Shibboleth login, I was trying to sign in again with my local DSpace account (after logging out of course). Accidentaly I forgot to type in my password, but DSpace "logged me in" (I was redirected to DSpace homepage), but instead of account name in the top-right corner of the page there was a blank space. When I clicked the empty button, it showed me links to "Profile" page and Logout. When I tried to access my account information, following error appeared:
The 'characters' parameter is required for list items.
Information from dspace log:
2017-08-03 10:00:12,537 INFO org.dspace.authenticate.PasswordAuthentication @ anonymous:session_id=7C194A481988A01BD9DC87D426AB4D9C:ip_addr=2001:718:1e03:5128:9e9e:1a6d:f958:dce:authenticate:attempting password auth of user=kakaka@kakaka.com
2017-08-03 10:00:12,538 DEBUG org.dspace.authenticate.ShibAuthentication @ Starting Shibboleth Authentication
2017-08-03 10:00:12,539 DEBUG org.dspace.authenticate.ShibAuthentication @ Received the following headers:
host='gull.is.cuni.cz'
connection='keep-alive'
content-length='55'
Cache-Control='max-age=0'
Origin='https://gull.is.cuni.cz'
Upgrade-Insecure-Requests='1'
user-agent='Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36'
content-type='application/x-www-form-urlencoded'
accept='text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8'
referer='https://gull.is.cuni.cz/password-login'
accept-encoding='gzip, deflate, br'
accept-language='en-US,en;q=0.8'
cookie='JSESSIONID=7C194A481988A01BD9DC87D426AB4D9C'
Shib-Cookie-Name=''
Shib-Session-ID=''
Shib-Session-Index=''
Shib-Identity-Provider=''
Shib-Authentication-Method=''
Shib-Authentication-Instant=''
Shib-AuthnContext-Class=''
Shib-AuthnContext-Decl=''
Shib-Assertion-Count=''
Shib-Handler='https://gull.is.cuni.cz/Shibboleth.sso'
eppn=''
affiliation=''
unscoped-affiliation=''
entitlement=''
targeted-id=''
persistent-id=''
primary-affiliation=''
nickname=''
primary-orgunit-dn=''
orgunit-dn=''
org-dn=''
... rest of the headers is also empty... log is continuing:
2017-08-03 10:00:12,539 DEBUG org.dspace.authenticate.ShibAuthentication @ Identified EPerson based upon Shibboleth netid header: 'epuid'=''.
2017-08-03 10:00:12,540 DEBUG org.dspace.authenticate.ShibAuthentication @ Updated the eperson's minimal metadata:
{{ Email Header: 'mail' = ''}}
{{ First Name Header: 'givenName' = ''}}
{{ Last Name Header: 'givenName' = ''}}
2017-08-03 10:00:12,540 INFO org.dspace.eperson.EPerson @ anonymous:session_id=7C194A481988A01BD9DC87D426AB4D9C:ip_addr=2001:718:1e03:5128:9e9e:1a6d:f958:dce:update_eperson:eperson_id=28
2017-08-03 10:00:12,544 INFO org.dspace.authenticate.ShibAuthentication @ has been authenticated via shibboleth.
2017-08-03 10:00:12,545 INFO org.dspace.eperson.EPerson @ :session_id=7C194A481988A01BD9DC87D426AB4D9C:ip_addr=2001:718:1e03:5128:9e9e:1a6d:f958:dce:update_eperson:eperson_id=28
2017-08-03 10:00:12,545 INFO org.dspace.app.xmlui.utils.AuthenticationUtil @ :session_id=7C194A481988A01BD9DC87D426AB4D9C:ip_addr=2001:718:1e03:5128:9e9e:1a6d:f958:dce:login:type=explicit
2017-08-03 10:00:12,546 DEBUG org.dspace.authenticate.ShibAuthentication @ Returning cached special groups.
2017-08-03 10:00:12,646 DEBUG org.dspace.authenticate.ShibAuthentication @ Returning cached special groups.
2017-08-03 10:00:12,646 DEBUG org.dspace.authenticate.ShibAuthentication @ Returning cached special groups.
DSpace behavior is the same even if I don't log in first using Shibboleth authentication method before Password authentication method. Behavior is the same even when trying to
log in with non-existent e-mail address (e-mail completely made up, no ePerson with this e-mail exists in DSpace).
In addition, empty ePerson appears in DSpace list of ePersons, without any name or e-mail.
Pictures are provided in attachment.
Additional information
My institutional account has two e-mail addresses assigned to it. Both e-mail addreses are already used for local DSpace account.
When I log in using Shibboleth authentication, DSpace pairs my institutional account with a local account identified by e-mail address that comes first in the Shibboleth e-mail
header.
Our authentication stack looks like this:
plugin.sequence.org.dspace.authenticate.AuthenticationMethod = org.dspace.authenticate.PasswordAuthentication, org.dspace.authenticate.ShibAuthentication, org.dspace.authenticate.IPAuthentication
Expected behavior
When logging using Password authentication and typing in wrong password or no password at all, I would expect standard password authentication behavior, e.g. flash message stat
ing that the provided login information is incorrect. I would also expect that DSpace won't redirect users back to homepage.
I am not sure if this is indeed a bug or some misconfiguration on our side, but I would be glad if anyone can provide me with suggestions what might be causing this problem and
how to solve it in case it is not a bug.
Thank you very much,
Jakub Řihák
Charles University, Prague - Czech Republic
DSpace 5.6
XMLUI (Mirage2 theme)
Attachments
Issue Links
- addresses
-
DS-3342 Shib login creates EPerson with null values
-
- Accepted / Claimed
-