COmanage Users List

[Benjeman Meekhof <>]

Hi Benn,

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.

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.

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.

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-