Add Openconext-Stepup config

[phavekes]

Overview

The configuration of Openconext-Stepup is stored in Stepup-Middleware. The configuration is pushed as JSON to a REST endpoint of this component.

The current configuration consists of three parts:

• Whitelist
  • The list of institutions (schacHomeOrganization) allowed to use the self-service portal.
  • Included in the stepup-institutions collection.
• Config
  • The email templates (to Middleware).
  • Data of the services allowed to use Stepup-Gateway as a SAML IdP, currently only SFO endpoints.
    • New collection: sfo.
    • Schema.
• Institution
  • The settings per affiliated institution.
  • This becomes the stepup-institutions collection.

Display in Manage

• 1 extra tab in the main menu: Stepup
• 2 sub-tabs: sfo, institutions

Stepup Middleware endpoints

• https://{{ middleware_vhost_name }}/management/configuration
• https://{{ middleware_vhost_name }}/management/institution-configuration
• https://{{ middleware_vhost_name }}/management/whitelist/replace

Changes in Stepup-Middleware

• Move email templates to disk

sfo collection

      {
        "entity_id": "http://institution.tld/stepup-mfa",
        "public_key": "MIID...",
        "acs": [
          "https://institution.tld:443/adfs/"
        ],
        "loa": {
          "__default__": "{{ stepup_uri_loa2 }}"
        },
        "assertion_encryption_enabled": false,
        "second_factor_only": true,
        "second_factor_only_nameid_patterns": [
          "urn:collab:person:uva.nl:*"
        ],
        "blacklisted_encryption_algorithms": []
      }

• loa: enum, 1 value
• acs: 1 value
• blacklisted_encryption_algorithms: array of strings

stepup-institutions collection

    {
         "identifier": "institution.tld",
         "use_ra_locations": true,
         "show_raa_contact_information": true,
         "verify_email": true,
         "allowed_second_factors": ["yubikey", "webauthn", "azuremfa"],
         "number_of_tokens_per_identity": 3,
         "use_ra": ["institution.tld", "other.tld"],
         "use_raa": ["institution.tld"],
         "select_raa": ["institution.tld"],
         "self_vet": true,
         "allow_self_asserted_tokens": false,
         "sso_on_2fa": false,
        "stepup-client" : "full"
   }

• use_ra, use_raa, and select_raa validate against identifiers from this collection.

• Field Stepup-client per IdP, enum with values: freerider or full.

• allowed_second_factors: enum with values 'azuremfa', yubikey, tiqr, webauthn and sms

Checklist

• Create schemas (re-use MetaData and auto-generate entityid
• GUI tabs and menu
• Server-side validation (hook)
• Config in Manage endpoints
• Push everything, no distinction between components

[baszoetekouw]

Look good! A few questions though:

• for institutions, is identifier a real schacHomeOrg? If so, should we make sure this is consistent with the IdPs tab? (i.e, check that sHO exists, and allow matching the correct IdP to the correct Stepup-entry?)
• Or, extending on that, should this entire stepup-institutions config perhaps be a new tab in the IdP-collection instead? (so make it additional config on an existing IdP instead of a new entity in the stepup collection)
• same question for the SSO entities: shouldn't these be "normal" SAML SPs with additional config instead?
• in institutions, should allowed_second_factor be an enum? What values are allowed?
• same question for blacklisted_encryption_algorithms in the sfo config

[phavekes]

No, the identifier is not always a existing schachome, ie vetting.surf.nl as virtual organisation.

For now, we keep these SFO entities a seperate collection.

Let's add blacklisted_encryption_algorithms with an empty default, so we don't have to change the middleware interface