Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


 COmanageHEXAAPerun
At a glanceImage ModifiedImage Modified
 
 Image Modified

Image Modified*

*this is the new ui

 
Image Added
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
ProfileA 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 notificationMass notifications can be sent at COUsA 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 onboardingmanual, 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 thingSP managers can define permissions and grant them to VO-s
 ProfileA 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.
 Member notification-A nice feature of HEXAA is that it is able to send a message to all VO or VO/Role members via email. 
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.
APIAPI for a considerable number of functions but not for templates, and other advanced stufffull 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 GUIit 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
 
deprovisioningplugins?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

  • GÉANT OP?
  • 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
    • TBA
 Roadmap1.1.1 is upcoming, with several new features useful for us (TBA)
  • New UI is upcoming

    as an eduTEAMS service

    Other deployments

    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