| | COmanage | HEXAA | Perun |
|---|
| At a glance |  |  | |
|---|
| |  |  *
*this is the new ui |  |
| User Facing features | | | |
|---|
| user Onboarding | Configurable enrollment flows - self sign-up
- email
- conscription with approval
- custom
| - email Invite, mass email invite
- URL, optionally with seat limit
- direct (by admin)
| Support for enrollment flows - Fully customisable application form with manual and automatic approval
- Direct onboarding to the group
- Email invitation
- Self sign-up
- Synchronization from external source (database, LDAP, file, ...)
- Periodical
- Manual (e.g. VO admin can search for user in external system and add him to the VO)
|
| VO structure | (VO-s in COmanage are called COs) - very flexible structure, arbitrary depth group and unit hierarchy
- separate sp permissions within units are not invented yet
| - VO and custom roles (+VO manager)
- 2 level structure
- roles can have their own subset of permissions within those available to the VO
| - VO and unlimited group hierarchy within the VO
- Internal roles: VO manager, VO observer (read-only), group manager
- External roles can be represented as groups or attributes
|
| Profile | A big drawback in my (Mihaly) opinion of COmanage is that profile data (User SSH key, email, etc) is not fully separated from VO data, thus the VO admin is able to change these without the knowledge of the user. | - Profile data and VO membership-based data are separated.
- Profile attributes can be different towards different SPs
- It makes sense to use HEXAA without a VO membership, since it can complement the data coming from the IdP with the HEXAA-based profile data.
| - Profile data and VO membership-based data are separated.
- Attribute modules which defines syntax checks, auto-fill and dependencies between attributes.
- Read/write access control for attributes
- SP get only required attributes (nothing more)
- Profile attributes can be different towards different SPs
- Attributes can be obtained from IdP or other external source or can be self-asserted (or combination)
|
| Member notification | Mass notifications can be sent at COUs | A nice feature of HEXAA is that it is able to send a message to all VO or VO/Role members via email. | - Enrollment related notifications are fully customizable by VO manger.
- Any other notification can be hooked to any event in the system.
- Multi-lingual support
|
| Service Management (not used in eduTEAMS shared) |
|
|
|
|---|
| SP onboarding | manual, in JRA3-developed sql db (as of v1.0.5) | 1) Login with any eduGAIN idp 2) select sp entityID 3) token is sent by email to contact info from metadata. The owner of those addresses becomes manager of the SP | - SP manager registers SP into Perun and then decide which VO and groups can access this SP and can specify additional conditions (access-rights, quotas, ...)
- SP can be any service. It's not limited to eduGAIN SPs
|
| SP managers | -(as of v1.0.5 - might be added in next version) | managers can invite additional managers | managers can invite additional managers |
| SP permissions | ?. It seems that we are not planning such thing | SP managers can define permissions and grant them to VO-s | SP managers can define permissions and grant them to VOs |
| Subscription to SPs | ? manual for now | "subscription model" 1) VO manager applies for public SP+permission 2) SP manager accepts application "invite model" 1) contact and deal is made off-band 2) SP admin generates token for permission and sends via email/etc. 3) VO manager connects by the token | contact and deal is made off-band |
| Technical features | | | |
|---|
| eduGAIN metadata integartion | - | all eduGAIN SP-s are automatically added to the system via cron+xsl script | Currently none. Possibly can be scripted using API. |
| API | API for a considerable number of functions but not for templates, and other advanced stuff | full API, the GUI itself uses the REST API | - RESTlike API via HTTP using JSON as data format.
- All functions all available via API.
- GUI and CLI uses the API.
- All API calls requires authorisation
|
| custom GUI | it should be possible to some extent, but no partial access | - Custom GUI possible, enables custom workflows.
- Example in production: NIIF HPC portal
- API users can manage their own VO, SP, Permission (everything) but only in their own security domain - no true admin access necessary for custom GUIs
| - Custom GUI possible.
- Usually use for one-purpose specialized "mini-applications".
- Can have own "service identity" or act as a user who is currently logged in.
- Perun act as OIDC resource server, therefore custom GUI can run on different hosts and can authenticate with Perun on behalf of the user
|
| deprovisioning | plugins? | hooks, that call urls with json parameters at defined events, like user removal from group | - Perun monitors changes within itself and can decide which services are affected by each change.
- Perun creates configuration file in any format (preferable something standardized) and then send it to destination via standardized channel (SSH, HTTP, ...)
- In case of SSH there is a small bash script which process obtained data. Usually just put the file in right place and reload the service.
- In case there is some error, Perun will try to push data again after a while.
|
| Development model | "COmanage, a project funded by the NSF and Internet2", details TBA | - HEXAA received GN3+ Open Call funding in 2013-14
- HEXAA is actively developed since then at MTA (Hungarian Academy of Sciences) SZTAKI (Institute for Computer Science and Control)
- MTA partially (up to the minimum Hungarian wage) refunds the wage of a certain number (<=25% of permanent stuff) employed students, if they are diploma-mentored by research fellows at Sztaki
- We can maintain 1-2 intern positions to federation-related stuff
| - Development funded by CESNET and Masaryk University in Brno
|
| Operation model | as an eduTEAM service | - hexaa.eduid.hu
- The eduID.hu federation and its operator KIFU relies on hexaa.eduid.hu instance for its internal and core services, hence it's operators monitor it as a core component
- Anybody with an eduGAIN user / SP can use this same instance on the side, but user support is limited
- as an eduTEAMS service
| as an eduTEAMS service Other deployments - Production instances
- Pilot instances
|
| Roadmap | Roadmap here: https://spaces.at.internet2.edu/display/COmanage/COmanage+Product+Roadmap | - consistent API v2 - same functionality, but easier to user for custom GUIs and scripts
- ORCID integration (currently in planning)
| - Better support for guest and sponsored accounts
- New GUI
- Synchronization of group structure from external source
|
