COmanage Users List

[Benn Oshrin <>]

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 account, which one do you pick?

(2) What happens when the eppn changes? Say I registered with

 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:>,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:>>
>  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
>     >
>