COmanage Users List

[Benn Oshrin <>]

On 9/8/17 10:14 AM, Benjeman Meekhof wrote:

> Thanks for your responses.  It sounds very much like 3.1.0 does
> exactly what I need in regards to user certificate DN as well as being
> able to self-service other identifier types that might come up.  It
> may be in my best interest to wait for the release rather than
> integrating something now depending on how long the wait is.

We are currently aiming to get the release done in time for TechEx next
month, but there are still a number of open issues so I'm guessing it
would be more likely that we would maybe get to release candidate status
by then.

That said, one option could be to deploy from the develop or feature
branches, at least for a test instance. (We have seen quite a few
deployers do this.) You can add yourself as a watcher to specific JIRA
issues to be notified when a commit you're interested in is available.

> Regarding the Certificate model, what LDAP schema/attributes would you
> use to store the DN?  I could choose to insert them outside COmanage
> for now and hopefully later when COmanage has the capability nothing
> would change (from the LDAP perspective).  Just the subject DN is
> perfect for our use case.

There is not an obvious answer to that question yet, as (for example)
the pkiUser object class's userCertificate attribute requires binary
encoding, which is not ideal. As part of our work with the CILogon
project, we are working on a set of recommendations for this sort of
problem, and hope to have a draft document available for community
review in time for next week's FIM4R meeting.

> Regarding your question about 'credentials', it is a little different.
> This is not 'self-service' information but rather information that
> might come as a result from a provisioning plugin which we want to
> make available for the user to view.  Considering it now I suppose it
> could just be some additional identifiers (or extended attributes if
> they could hold longer strings) which we put information into - maybe
> there is nothing new required in that case.

v3.1.0 allows identifiers to be associated with provisioning targets.
You can see an example here:

https://github.com/Internet2/comanage-registry/blob/a1084138c6ce2d04b8ff2ffb8896f15562cd9880/app/AvailablePlugin/MailmanProvisioner/Model/CoMailmanProvisionerTarget.php#L322

Thanks,

-Benn-

> Thanks again for the information, helps a lot.
> 
> regards,
> Ben
> 
> 
> On Fri, Sep 8, 2017 at 8:11 AM, Benn Oshrin 
> <>
>  wrote:
>> On 9/7/17 4:20 PM, Benjeman Meekhof wrote:
>>
>>> I'm looking to add some custom attributes to CO person identities.
>>> Some self-service, some populated from external sources (maybe via
>>> REST API).  From everything I have read and tried this seems
>>> impossible to do easily.  Here's what I think I know:
>>
>> By way of background, extended attributes were always intended to be a
>> simple and quick method of extending the data model, with more
>> sophisticated requirements requiring the use of a custom plug-in. With
>> that said, more comments below...
>>
>>> - Extended attributes are limited to 32 character strings or other
>>> not-useful-to-me data types.  Also it appears they are not allowed to
>>> be self-serviced by CO people.
>>
>> The limitation of extended attributes datatypes stems from the limited
>> number of datatypes that are available in SQL across database
>> implementations. Extended attributes attach to the CO Person Role
>> record, which has no provision for self-service at the moment.
>>
>> The internal implementation of extended attributes has turned out to be
>> problematic for various reasons, and we are currently considering
>> replacing it with a new approach.
>>
>>  https://bugs.internet2.edu/jira/browse/CO-1478
>>
>> We would be interested in any comments or suggestions, which can be
>> added directly to that ticket.
>>
>>> - Adding an extended Identifier type almost seems like the right track
>>> but I can't make this self-service once the user is enrolled.
>>
>> Although this ticket doesn't yet have a fix version, we expect
>> self-service capabilities for identifiers to be available in 3.1.0:
>>
>>  https://bugs.internet2.edu/jira/browse/CO-1255
>>
>> (The initial commit could be made in the next couple of weeks as part of
>> a larger effort.)
>>
>>> - Organization identifiers seem like they could work for part of what
>>> I want also but can't be self-service.
>>>
>>> The idea here is I just want all potential information to be easily
>>> viewable and/or editable under the CO person identity interface.  For
>>> one example, I'd like them to be able to associate a CILogon subject
>>> string with an identity in our CO not unlike an SSH key can be
>>> associated already.
>>
>> As part of CO-1446, a Certificate model similar to the SshKey model will
>> be introduced in 3.1.0. (It will probably support subject and issuer
>> DNs, and not the full certificate, at least initially.)
>>
>>> Or another:  I'll be writing some new service
>>> provisioning plugins.  I'd like the credentials for those services to
>>> be available to the user in the COmanage identity web interface so
>>> they can plug them in to where they need them.
>>
>> What do you mean by "credentials"? Is that different than the items
>> (such as certificates) already mentioned?
>>
>>> What are my options here for extending the person fields/attributes?
>>> It's looking very much like my only option is writing a plugin to
>>> provide a new view.
>>
>> Right now, that's probably correct, although it sounds like many of your
>> use cases will be solved at various points in upcoming releases.
>>
>> There's also this related request
>>
>>  https://bugs.internet2.edu/jira/browse/CO-1474
>>
>> although the specifics mentioned in that ticket seem like they would be
>> addressed by the proposal for better cluster account management (CO-866).
>>
>> Thanks,
>>
>> -Benn-