COmanage Users List

[Benn Oshrin <>]

We would typically create an Extended Type (like Mike's email) with some
name like "Collaboration ID" (though you could also use an existing
Identifier type like "Enterprise") and then populate that into LDAP as
(the perhaps not ideally named) employeeNumber.

Starting in Registry v3.2.0 (and available now in the develop branch) we
would recommend the use of the new voPersonID attribute, which is
designed exactly for this use case. You can read more about voPerson at
https://voperson.org/.

Whichever attribute you pick then becomes the unique portion of your DN:
vopersonid=UMD123456, ou=Users, dc=test, dc=umd, dc=edu. This way the DN
doesn't change if other attributes about the user change. Specifically
you are using your generated identifier as the key, not an external
identifier (ePUID or ePPN from another institution, etc).

Whether this identifier is suitable for use in your own asserted
eduPersonUniqueId is probably worth some discussion. While the platform
ID meets almost all of the requirements for ePUID, ePUID considers the
identifier "public", which a platform identifier may or may not be
(depending presumably on local policy).

Thanks,

-Benn-

On 8/29/18 2:55 PM, Kevin M. Hildebrand wrote:
> Reviving a very old thread...
> 
> I understand your recommendation about not using eppn in the dn.  When
> generating the opaque identifier as you suggest, what attribute would
> you suggest I use to hold that identifier?  What's a good practice for
> building a dn?  I was using dn: 
> ,
> ou=Users,dc=test,dc=umd,dc=edu,  and copying the
> eppn to the uid field as they'll both be the same here. 
> Would this be an appropriate use for eduPersonUniqueId?  (dn:
> ,ou=Users...)
> 
> Thanks,
> Kevin
> 
> 
> 
> 
> On Thu, Apr 13, 2017 at 8:55 PM Benn Oshrin 
> <
> <mailto:>>
>  wrote:
> 
>     To reply with more detail...
> 
>     For the most part what you're asking for is
>     https://bugs.internet2.edu/jira/browse/CO-1137 (which I think is what
>     was brought up a few days ago on list). The complication is that even
>     when we implement that capability (I think we're trying to get it done
>     for the next feature release), you'll still run into the issue that eppn
>     is attached to the org identity, and not the CO Person record.
> 
>     I could offer a couple of options for how to work around that
>     (pipelines, enrollment forms, new RFEs related to the new $ENV OIS we're
>     planning), but instead I'd actually rather push back and suggest that
>     eppn might not be the best choice for a DN component, which needs to
>     uniquely identify a person in LDAP.
> 
>     (1) What happens if a person has more than one eppn? If they've linked a
>     gmail account and a university.edu <http://university.edu> account,
>     which one do you pick?
> 
>     (2) What happens when the eppn changes? Say I registered with
>     
> 
>  
> <mailto:>
>  but then later decide I
>     don't want my personal gmail
>     address associated with the registration. (COmanage can handle a DN
>     change, but downstream applications might not be able to.)
> 
>     A better approach is to use Identifier Assignments to create a CO
>     specific opaque identifier (something like "UMD123456") and then use
>     that to populate the DN. This way there is a one to one relationship
>     between a CO Person identifier and an LDAP DN, and it doesn't change
>     based on external factors. You can still look up records based on eppn
>     by having the LDAP Provisioner write the eppn into the LDAP record.
> 
>     Thanks,
> 
>     -Benn-
> 
>     On 4/10/17 6:04 PM, Kevin M. Hildebrand wrote:
>     > That works for most of the ldap attributes but I can't create a dn
>     that
>     > way.
>     > I'd like my dn to have the eppn in it, and have the uid match.
>     > i.e.,
>     > dn: 
> 
>  
> <mailto:>
>     
> <mailto:
>     
> <mailto:>>,dc=test,dc=umd,dc=edu
>     >
>     > I was thinking, perhaps an expansion of the fields available in the
>     > automatic identifier assignment would help- right now you can build
>     > identifiers with tokens from the user's name, how about expanding that
>     > to allow more generic expansion.
>     > Then I can build uid from eppn, and use that for my dn.
>     > Alternatively, the dn creation options should also allow one to pull
>     > values from the org record.
>     >
>     > Kevin
>     >
>     > On Apr 10, 2017 18:21, "Benn Oshrin" 
> <
>     
> <mailto:>
>     > 
> <mailto:
>  
> <mailto:>>>
>  wrote:
>     >
>     >     In the LDAP provisioner attribute configuration, you should see an
>     >     option "Use value from Organizational Identity" that does what
>     you want.
>     >     I thought this was documented in the wiki somewhere, but I can't
>     >     find it...
>     >
>     >     (In general you can't export Org Identity attributes because
>     they're not
>     >     "operational", but there are limited exceptions primarily for
>     this use
>     >     case.)
>     >
>     >     Thanks,
>     >
>     >     -Benn-
>     >
>     >     On 4/10/17 9:06 AM, Kevin M. Hildebrand wrote:
>     >     > I'm having some challenges creating the LDAP dn that I want
>     based on
>     >     > attributes obtained via self-signup.
>     >     >
>     >     > I've got authenticated self-signup working, using Google
>     auth.  That
>     >     > populates ePPN in the Organizational Identity with the
>     >     authenticated ID
>     >     > (I'm currently having it use the Google user's email address).
>     >     >
>     >     > The problem I'm having is that the LDAP provisioner only
>     seems to want
>     >     > to draw items from the CO person record, and self-signup doesn't
>     >     > populate that record with much.
>     >     >
>     >     > For example if I set my 'People DN Identifier Type' in the
>     provisioner
>     >     > to ePPN, the provisioning fails because ePPN isn't defined
>     in the CO
>     >     > person record.
>     >     >
>     >     > I'd like to have the authenticated ID passed in from Google get
>     >     assigned
>     >     > to ePPN in a form available to the LDAP provisioner so I can
>     build
>     >     a DN
>     >     > from it.  Perhaps by automatically copying it to the CO
>     person record,
>     >     > or perhaps a way to allow the LDAP provisioner to export
>     >     attributes from
>     >     > the Organizational record.
>     >     >
>     >     > Thanks,
>     >     > Kevin
>     >     >
>     >     > --
>     >     > Kevin Hildebrand
>     >     > University of Maryland, College Park
>     >     >
>     >
>