Allow eduPersonTargetedId as username (SHHAA)

[twagoo]

persistent_id should be added to authorization part of SHHAA configuration

Then, #156 should also be fixed.

Notifiy Torsten Compart <​grigull@informatik.uni-leipzig.de> when fixed

On 12/10/11 14:02 , Torsten Compart wrote:

Hi Dieter,

after an internal discussion about the attributes of our IDP send to the
component register. You said, that 'eppn' (eduPersonPrincipalName) would
be required. This would mean, that the Component Register uses an
attribute which is the authentication token of the whole CLARIN network
used for every other SP too. We could provide the less explicit
attribute 'persistent_id' (eduPersonTargetId), which would be generated
by our IDP only for the Component Register. I think for the purpose of
the Component Register this would be enough. Would it be enough to
release the attribute 'persistent_id' for a successful authentication?
This would help to clear the discussion with our data protection officer.

Hi Torsten,

I think that should be sufficient. It means however that we need to make
some changes to the implementation of the Component Registry in that it
queries the user to provide a "human readable" name after logging in
when eppn or displayname is not available. I think you can tell your
data protection officer that we can live with that solution.

It might take some time on the other hand before you really can login at
the component registry. I'm cc'ing Twan, he can add you to the ticket
for this so that you get a signal as soon as eptid is supported.

[twagoo]

attribute is called eduPersonTargetId, not persistent_id

[twagoo]

See comment:3:ticket:156, in ComponentRegistry-1.11 users will be able to edit their displayname. So with 1.11 eduPersonTargetId can be added.

[twagoo]

eduPersonTargetId -> eduPersonTargetedId

On 4/12/12 12:13 , Torsten Compart wrote:

Hi Twan,

thank you for your efforts. That are really great news. Your testing
page confirmed the current policy of our administration.
We currently send only to attributes:

Digital ID Card
eduPersonAffiliation *staff*
eduPersonScopedAffiliation *​staff@uni-leipzig.de
<​mailto:staff@uni-leipzig.de>*

We will discuss the next steps, so that we could send at least the
eduPersonTargetedId via our IdP for an user identification against a SP.
Currently this attribute seems to be the only way to be allowed by our
data protection officer without publishing non-anonymous user related
attributes (name, email etc.).

[Twan Goosen]

All open Component Registry tickets not on a milestone have been put on ComponentRegistry-1.15. Re-assignment to later milestones is likely for some of these tickets.

[Twan Goosen]

​https://github.com/clarin-eric/component-registry-rest/issues/19