Skip to end of metadata
Go to start of metadata

When you want to connect a service to the SCZ using OpenID Connect (OIDC), until we support self registration, the following steps are to be taken.

OIDC metadata

You need to send us the OIDC metadata of your .well-known endpoint so we can manually put this into our system. Contact us about your intention to connect via OIDC. We need a SP-name, a SP-description and a well-known-end point to configure the connection on our end. Fyi on what that looks like:

  • "<SPname>": {
        "application_type""web",
        "client_name""<SP-description>",
        "subject_type""public",
        "client_secret""****",
        "response_types": [ "code"],
        "redirect_uris": [
                            "https://<sp-URL>/gender2/oauth2/scz/reply"
                          ],
        "client_id""<SPname>",
        "client_secret_expires_at"0,
        "client_id_issued_at"0
    }

Upon completion, we will send you a secret to be used on your end. You can find our .well-known endpoints at https://proxy.pilot.scz.lab.surf.nl/.well-known/openid-configuration.

 

Configure the service in COmanage

A CO is needed in COmanage, so if there isn't any yet, we will need to create it and invite someone from your side to be admin of the CO.

As CO admin, you need to connect your service to the CO in SCZ COmanage. Log in to the SCZ and go to your CO. Choose Configuration/Services/Add service. Fill-out the form as shown below (with your SP-data):

Name, Description and service URL are text fields, Service Group can't be empty (choose CO:member:all to enable access to the SP for all members of the CO).

At Entitlement URI the OIDC clientid needs to be filled out; this is currently is kind of a hack, and a proper solution is on the COmanage roadmap.

Configure provisioning in COmanage

Now a Zone Provisioner needs to be configured in COmanage. This makes it so information about groups, people and services will be written in the database the SCZ uses during an authentication. To do this, in the SCZ, in your CO, go to Configuration/Provisioning Targets and add a new provisioner with the following settings (insert your SP-data were appropriate):

After this is saved, the actual provisioning is necessary. For this click "Reprovision all" in the Provisioning targets screen of COmanage.

Please mind: changes to services don't automatically initiate a new provisioning action. Every time a Service is added or changed, you need to do a "Reprovision all" manually so existing persons will be updated if necessary. 

OIDC - explicitly ask for attributes

You need to explicitly request attributes to receive them:

 

OIDCScope "openid email profile address phone"
OIDCAuthRequestParams claims={"userinfo":
{"edumember_is_member_of":null,"schac_home_organisation":null,"eduperson_affiliation":null,"nickname":null,"name":null,"uid":null,"email":null,"family_name":null,"eppn":null,"address":
{"street_address":null}}}

 

You see a part of our apache auth_openidc_module configuration. Without this, SATOSA will only send the standard profile attributes.
The edumember_is_member_of attribute contains the CO groupmembership information for the authenticated user.
Mind you: it might be you don't need all the info requested or the scopes in the above code statement.
Below is the output from our OIDC Test RP after successful connection and login by a member of a connected CO. De CLAIM_ prefix comes from the apache  auth_openidc_module:
 

 

CLAIM_nickname: Pietje Puk
CLAIM_eduperson_affiliation: affiliate
CLAIM_uid: pietje.puk@foobar
CLAIM_edumember_is_member_of: Foobar:CO:members:all,Foobar:CO:members:active
CLAIM_given_name: Pietje
CLAIM_sub: d0e48f8a10dec569c7df6817cd49c5c11b0758849788ae9a38433debecb895eb
CLAIM_aud: oidctest
CLAIM_nonce: obZufCcMkNHoLqGA7uyBISPVmKoIyzIdYBYT_BxFEr0
CLAIM_at_hash: 903JrSTyqDdyMmXY3kcZ1A
CLAIM_iat: 1527002090
CLAIM_exp: 1527005690
access_token: 9159bd7c7308489ca5fc4054181f696a
access_token_expires: 1527005690
  • No labels