Becoming an HDF Service#

Organisational#

Services in HDF need to specify with Virtual Organisations they want to support. Thereby, they delegate the right to specify members to the VO Administrator.

Services can specify requirements on the quality of the user identities (assurance), i.e. whether they need to have a working contract with their home institution, or whether a social identity is good enough.

Test VO: HDF#

We are creating an “HDF” VO, in which all users will be integrated, when they sign up with HDF. This VO SHOULD be supported by all services, if need be with a low quota. You SHOULD do additional filtering on the allowed users based on the assurance, so that for example, you don’t give Virtual Machines to any github user.

Technical#

HDF is capable of supporting OpenID Connect (OIDC) and SAML. Here we only describe OIDC. If you are sure you need SAML, please contact Marcus Hardt and Sander Apweiler.

OIDC#

For OIDC you need to register a client in the => unity production instance. You need to click on the top right “No account/sign up”. Here’s some explanation for a few fields (Note: mouse-over also displays help):

• User Name is the OIDC client_id (you can choose it)
• Password is the OIDC client_secret (you choose it)
• Email Address is an email address for contacting the admin of the service
• Service Security Contact is the security responsible of the service. This may be additional people, for example in a hosted VM setup
• Site Security Contactis your computer centre security contact. Typically your CERT.

• Service DPS URL: This is your Data Privacy Statement (DPS). Required by law. Find a DPS template here

• The well_known configuration of login is here:

https://login.helmholtz.de/oauth2/.well-known/openid-configuration

Note#

Please inform the HDF AAI Mailinglist about which VOs you support. We’d like to keep track of that information on this table.

Service Specific Configuration#

• OIDC apache module: => mod_auth_openidc
• OpenStack Configuration for OIDC:
  • => Originally created for HBP
  • => map entry from EGI

Policy#

For policy reasons we need several points:

• Service Security Contact: This contact MUST be able to provide information about user logins to the security people in case of a security incident. Please also make sure you are following the => SIRTFI recommendations.

• Data Privacy Statement: This is a legal requirement. Luckily we do have a GDPR compliant DPS template into which you only have to insert the specifics of your service.

• Acceptable Use Policy: The AUP Template is what the users will have to “accept” before entering a VO. This may or may not be acceptable for services at your research centre. It is up to you to make sure. (Note: for KIT we are in the process of getting the permission to use the general AUP as an alternative to our “IUK Ordnung”.)

• Finally, you need to comply with the Data Protection Code of Conduct DPCOCO-2.0.