COmanage Users List

[Benn Oshrin <>]

On 10/24/16 10:26 AM, Mihály Héder wrote:

> -In our understanding every detail of the CO population can be modified
> by the CO admins. E.g. the admin of a CO can override a member’s ssh
> certificate, email, etc. Is there any way to limit the attributes the CO
> admin can change? Preferably, the CO admins should only be able to
> change group membership, affiliation, etc. and the rest only to be
> changed by the users themselves. Niels forwarded us the essence of Ben’s
> answer to this question  - in the upcoming new COmanage version the data
> coming from an Organizational Entity cannot be modified. That could be
> useful if we could modify the list of attributes that can only be stored
> there.

CO Admins are basically considered "super users" within a CO, and so 
generally there is not an ability to restrict their privileges.

> -The problem we have in mind is that the ability of the CO admin to
> modify e.g. ssh pubkey and therefore impersonate a member at some
> service rules out certain types of trust relationships within the CO.

The counter argument is that some users mess up their own stuff and need 
someone with more privileges to help them out. BTW, Organizational 
Identity Sources won't help this scenario, since SSH Keys can be managed 
after enrollment.

I think effectively what you are proposing is a new "moderately 
privileged" administrator. Sort of like a COU Admin (who can only manage 
records for people within the COU they manage), but with more flexible 
permission capabilities. Almost like how Self Service Permissions 
(https://spaces.internet2.edu/display/COmanage/Self+Service+Permissions) 
can be enabled or disabled for end users. I think it would be useful to 
consider such a capability, but it would be non-trivial to add it.

> -Also, we are uncertain how the Organization Identity Pooling setting
> affects this part. To be more specific, we want to create one unique
> identifier for each physical person, so that is definitely something
> that cannot be stored on per CO bases. Also we’d like to work in a way
> where each user have some “profile” which is independent of COs and
> where the user can link his identities, or manage hit attributes
> (e-mail, sshkeys, …). Is it possible to configure COmanage in such way?

The problem with relying on Organizational Identity Pooling for this is 
you are constrained to the somewhat limited attributes and capabilities 
attached to Org Identities, which are really designed to reflect 
external identities. Also, we're likely to deprecate the Pooling 
capability in a future release.

That said, we've seen a couple of use cases like this before, and there 
are some options for handling it.

One would be to set up a separate CO that serves to create the core 
profile. Let's call that the "Profile CO", and it would be where the 
user links identities and uploads SSH Keys. You can then provision out 
of the Profile CO into each additional CO, though this would require 
some custom integration coding (made easier in v1.1.0). A variation of 
this approach would be to put the Profile CO in a completely separate 
COmanage instance.

Another approach would be to only create one big CO. Then each thing 
that you thought would be a CO would actually be a COU within the big CO.

> -About API access: Do you have an API in comanage for creating
> Enrollment flow templates or enrollment flows? Is there a way to create
> a user from the scratch through the API?

There is not currently an API for enrollment flow configuration. (We 
simply haven't had a use case for it yet.)

You can create a user from scratch, right now it involves adding each 
data element one by one. So

(1) Add Organizational Identity
(2) Add Org Identity Name and other attributes
(3) Add CO Person
(4) Add CO Person Name and other attributes
(5) Add CO Person Role
(6) Add CO Org Identity Link

> -Is there a way to implement a script via a hook that makes a decision
> in an enrollment flow at some point? Use case: we want to make a
> decision about whether to accept a self-registration based on the home
> organization of the user. This information can be made available for
> comanage via shibboleth or it can be derived from the EPPN. The user
> should either be allowed to complete the registration normally or denied
> from self-registering but still be presented with a meaningful error
> message.

Yes, you can write plugins and interject them at various points.

 https://spaces.internet2.edu/pages/viewpage.action?pageId=87756108
 https://spaces.internet2.edu/display/COmanage/Enrollment+Flow+Plugins

One way to do what you propose would be to check the IdP, and if not 
acceptable update the Petition to denied status and redirect to an error 
page rather than the "done" URL.

That said, we've gotten the feature request from multiple sources, and 
the dev team is currently considering ways to support it.

> -Is there documentation describing allowed characters for identifier
> values? (CO name, group name,  …) within COmanage?

I don't think there's documentation, but generally there are no 
restriction on names unless stated on the configuration page in 
question. There may be some downstream impacts, though. For example, if 
you provision a group to an application, and that application doesn't 
like a given character.

> -It is possible to create an invitation-based enrollment flow that lets
> you select during the invitation which group or COU do you want to
> invite someone?

Yes. For a COU, when defining the COU enrollment attribute simply set 
"modifiable" and "required" to true. Groups are slightly more 
complicated, and are described in the "Default Values for Attributes" 
section here:

https://spaces.internet2.edu/display/COmanage/Registry+Enrollment+Flow+Configuration#RegistryEnrollmentFlowConfiguration-EnrollmentFlowAttributes

Thanks,

-Benn-

> Cheers
> Mihály
>
>
>
> --
> Mihály Héder, PhD
> Research Fellow
> Institute for Computer Science and Control
> Hungarian Academy of Sciences