comanage-users - [comanage-users] Various questions about COmanage
Subject: COmanage Users List
List archive
- From: Mihály Héder <>
- To:
- Subject: [comanage-users] Various questions about COmanage
- Date: Mon, 24 Oct 2016 17:26:20 +0200
- Ironport-phdr: 9a23:4v4ODRSq76pfnaJ3mYeLHyrFNtpsv+yvbD5Q0YIujvd0So/mwa67YxKN2/xhgRfzUJnB7Loc0qyN7PCmBDdLuMvJmUtBWaIPfidNsd8RkQ0kDZzNImzAB9muURYHGt9fXkRu5XCxPBsdMs//Y1rPvi/6tmZKSV2sfTZyc+/yH4fUhsu6kv2p9ofISwROmDenZ75udlO7oRiCmNMRhN5HK6a4zgqBgvpEdv4ekWZpJVuXjlD868u95rZ44ThZuPNn8tJJF6XnKfdrBYdEBSgrZjhmrPbgsgPOGFOC
Hello list,
during our work on the eduTEAMS service (that will be implemented with COmanage), some questions emerged about the tool:
-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.
-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.
-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?
-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?
-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.
-Is there documentation describing allowed characters for identifier values? (CO name, group name, …) within COmanage?
-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?
Cheers
Mihály
--
Mihály Héder, PhD
Research Fellow
Institute for Computer Science and Control
Hungarian Academy of Sciences
during our work on the eduTEAMS service (that will be implemented with COmanage), some questions emerged about the tool:
-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.
-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.
-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?
-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?
-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.
-Is there documentation describing allowed characters for identifier values? (CO name, group name, …) within COmanage?
-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?
Cheers
Mihály
--
Mihály Héder, PhD
Research Fellow
Institute for Computer Science and Control
Hungarian Academy of Sciences
- [comanage-users] Various questions about COmanage, Mihály Héder, 10/24/2016
- Re: [comanage-users] Various questions about COmanage, Benn Oshrin, 10/24/2016
Archive powered by MHonArc 2.6.19.