Task #3617
Address LTERN Authentication Service's incorrect DN creation issue
100%
Description
For testing, I recently used my LTER account to log into https://cn.dataone.org/portal using my uid=cjones1,o=LTER,dc=ecoinformatics,dc=org DN. I was redirected to the LTERN Shibboleth service, and logged in. The DN that was created was:
CN=Christopher Christopher A6677,O=LTERN (Long Term Ecological Research Network),C=US,DC=cilogon,DC=org
Perhaps this is an isolated issue, but the Surname was set to the Givenname. After looking at my LDAP entry, things look correct:
dn: uid=cjones1,o=LTER,dc=ecoinformatics,dc=org
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: uidObject
cn: Christopher Jones
sn: Jones
uid: cjones1
givenName: Christopher
mail: cjones@nceas.ucsb.edu
o: LTER
ou: NWK
Please check that the surname mapping is correct for CILogon DNs. Thanks!
History
#1 Updated by Mark Servilla over 11 years ago
- % Done changed from 0 to 10
I have confirmed that the mapping in the Subject field CN is replicating the givenName to the surName element.
#2 Updated by Mark Servilla over 11 years ago
- Status changed from New to Closed
- % Done changed from 10 to 100
- translation missing: en.field_remaining_hours set to 0.0
This issue is the result of a misconfigured attribute definition file in the LTER Shibboleth deployment; the surname attribute definition in the default attribute-resolver.xml file was misconfigured for camel-case use: "surname" should be "surName". In this case, the attribute filter was not able to provide the surName attribute to the relying service (CILOGON), which apparently reused the giveName in both the givenName and surName fields.
The attribute definition was renamed to "surName" and Shibboleth was restarted via a restart of Tomcat; the attribute filter is now passing both givenName and surName correctly. This change was tested with the CILOGON service (https://cilogon.org/?skin=DataONE) and confirmed to report both givenName and surName correctly.
This ticket will now be closed.
