Page History

*

*this is the new ui

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

• Enrollment related notifications are fully customizable by VO manger.
• Any other notification can be hooked to any event in the system.
• Multi-lingual support

• 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

"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

• 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)

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

• 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.

• 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

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

as an eduTEAMS service

Other deployments

• Production instances
  • CESNET - https://www.cesnet.cz/services/perun/?lang=en
  • EGI - https://wiki.egi.eu/wiki/Perun
  • ELIXIR - https://www.elixir-europe.org/services/compute/aai
  • BBMRI - https://bbmri-eric.eu
  • WestLife - https://west-life.eu
  • de.NBI - https://www.denbi.de
  • Masaryk University - https://muni.cz
  • UMPRUM - https://www.umprum.cz
• Pilot instances
  • LifeScience AAI

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