Versions Compared


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


After the above technical connection has been taken care of, a service needs to be connected to a CO in our Membership Management Service (MMS, for example COmanage) before receiving attributes stored in COmanage the MMS (enter the entityID of the SP for "Service URL" and "Entitlement URI" for the CO that needs access to that SP and specify 'Zone Provisioner' as provisioning target). As

Some points of attention

  • Attributes are not passed from the IdP of the user to the SP: the attributes received from the IdP are (partly) used for SCZ. SCZ will look up your account info in the MMS (COmanage) and use the attributes found internally to pass to the SP. So: while you might see attributes from the IdP, in case the configuration in SCZ/COmanage MMS isn't right, you might not receive attributes at the SP
  • Before you receive attributes, at least the following needs to be catered for:
    • the SP needs to be connected to the SCZ
    • the IdP of the user needs to be connected to the SCZ
    • in SCZ a CO needs to be created and a CO-admin needs to be enrolled
    • in SCZ a zone provisioner needs to be defined for your CO and SP
    • you will only receive attributes from identities that are member of your CO
    • the login proxy gets its data from a 'connection database' in which the CO attributes are provisioned. De relevant database table is updated whenever a new member is added to the CO while the ZoneProvisioner of the CO is set to  "automatic". To provision all attributes to existing members, that existed before the ZoneProvisioner was configured, the "reprovision all" button needs to be clicked
    • you need to set up groups within your CO, maybe COU's, and define an enrolment for your CO, so people can register. Please
  • See the underlying pages for specific cases, like for example with OIDC, you need to specifically request attributes