Skip to Content.
Sympa Menu

comanage-users - Re: [comanage-users] Various questions about COmanage

Subject: COmanage Users List

List archive

Re: [comanage-users] Various questions about COmanage

Chronological Thread 
  • From: Benn Oshrin <>
  • To:
  • Subject: Re: [comanage-users] Various questions about COmanage
  • Date: Mon, 24 Oct 2016 16:47:31 -0500
  • Ironport-phdr: 9a23:z320bxSr1b6uiVTQl0fsFBRI5dpsv+yvbD5Q0YIujvd0So/mwa67YhyN2/xhgRfzUJnB7Loc0qyN7PCmBDdLuMvJmUtBWaIPfidNsd8RkQ0kDZzNImzAB9muURYHGt9fXkRu5XCxPBsdMs//Y1rPvi/6tmZKSV2sfTZyc+/yH4fUhsu6kv2p9ofISwROmDenZ75udlO7oRiCmNMRhN5IJ6A3gjzSomFJfawCz25uI1W7nhDg69228YI5tSlcpqRypIZ7TazmcvFgHvRjBzM8PjVt6Q==

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

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 ( 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

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

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:




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

Archive powered by MHonArc 2.6.19.

Top of Page