SP Registry

Service for registering services to login.helsinki.fi or LDAP and managing their information.

• • Logging in and user rights
    • Service Providers
    • Summary
    • Basic information
    • Technical Attributes
      • SAML
      • OIDC
      • LDAP
    • Attributes
      • LDAP memberOf
    • Certificates (SAML only)
    • SAML Endpoints (SAML only)
    • Redirect URIs (OIDC only)
    • User Groups (LDAP only)
    • Contacts
    • Admins
    • Test Users (SAML and OIDC only)
    • View Metadata (SAML only)
    • Login Statistics (SAML and OIDC only)
  • Adding new services to SP-Registry
    • SAML / OIDC
    • LDAP
  • Removing a service from SP-Registry and the production servers

Logging in and user rights

Service URL: 

https://sp-registry.it.helsinki.fi/

SP-Registry uses single sign on, so you should click the Single Sign On icon on the front page. University employees get an automatic right to add new services.

If you are not verified as a university employee during login, please contact atk-autentikointi@helsinki.fi after login, so that an administrator can add the necessary user rights for you. If necessary, an administrator can also create local usernames for SP-Registry.

OBS. If you are already using login.helsinki.fi (SAML and OIDC) or LDAP and don't see your service, please have service owner or administrator (in the University of Helsinki Application portfolio) ask access form atk-autentikointi@helsinki.fi.SP-Registry structure

Service Providers

Displays a list of services for which you have administrator's rights. You can see more information about a service by clicking its identifier.

There is separate list for SAML, OIDC and LDAP services and you can add new service by clicking the "Add a new" button.

Summary

Displays the service information and potential changes after the previous validation.

Potential missing information and information required for production use are also shown at the start of the page.

You can find a button at the end of the page to delete a validated service that is not in production use. This will hide the service entirely. The service can only be restored for a maximum of one year; if you need to restore it, please contact an administrator.

The 'Organization' and 'Admin notes' fields visible on the page are only for administrators' use.

Basic information

Basic service information and notes.

• Service name and Service description
  • Please fill these in in all languages that service uses.
  • For SAML and OIDC services, names and descriptions are shown to users during login.
  • If some language is missing, languages are used in order en -> fi -> sv.
• Privacy policy URL
  • If you are using generic University of Helsinki Data Protection URLs, just check "Privacy Policy URLs from Organization" and check that selected organization is University of Helsinki.
• Application porfolio URL
  • Only services in the UH Application portfolio can be added to SSO or LDAP. https://workgroups.helsinki.fi/display/sovellussalkku (required login).

Technical Attributes

Depending on the service type. Technical specifications.

SAML

• Entity Id
  • Must be unique and in URI format. Common practice is to use service URL with ending, i.e. "https://sp-registry.it.helsinki.fi/sp". If you need something other than URI, please contact IdP administration.
• Discovery Service URL
  • If the service is federated and uses multiple IdPs as sources, provide the IdP selection page address here. Most can ignore this.
• Nameidformat
  • If you use attributes for user identification, you may not need these.
  • For more information, visit https://wiki.shibboleth.net/confluence/display/CONCEPT/NameIdentifiers
• Sign SSO assertions
  • The IdP signs the user data/attributes it sends to the service. Usually off, as responses are signed.
• Sign SSO requests
  • The IdP requires that the authentication requests sent by the service are signed. If the service supports this, it is advisable to enable this setting.
• Sign SSO responses
  • The IdP signs the responses it sends to the service. If this is not on, the service cannot trust the messages sent by the IdP, as they could be falsified by the user in between.
• Encrypt SSO assertions
  • The IdP encrypts the user data/attributes sent to the service. This should always be done, but some SAML SP implementations do not support encryption. This is likely to become mandatory in SAML2 specifications.
• Subject Identifier
  • Request SAML subject identifier. Service can request either subject-id or pairwise-id. See https://wiki.helsinki.fi/xwiki/bin/view/SO/User%20management/login.helsinki.fi/#HUseridentifiers
• Require MFA authentication
  • User is redirected to Azure for MFA authentication. Does not work with the Test service.
  • If this is on, and the service requires specific login method (rare case) authentication will fail.
• Use SHA-1 as signature algorithm
  •  Used if the service does not support the SHA-256 algorithm, which is the default. Primarily, the service's SAML application should be updated to a more modern one.
• Force use of specific nameIDFormat
  • Enforces a specific nameIdFormat value, selecting the desired format from the list above.
  • Required only with the "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" value, where the uid-parameter is defaulted as the nameid (add this to the attributes delivered to the service). Do not use if you do not know what you are doing.
  • Only antique SAML implementations and services might need this and even in those cases, they usually do not need it even if they claim so.
• Publish to production servers
  • The service is linked to the login.helsinki.fi production servers, allowing login with any HY user credentials.
  • This requires separate approval from the Shibboleth service administration
• Publish to test servers
  • The service is linked to the login-test.it.helsinki.fi test server.
  • Changes take effect automatically, and you can configure test users in the Test Users section. 
• SAML product this service is using
  • Which SAML SP implementation are you using?
• SP updates IdP metadata automatically
  • It is advisable that the service is configured to update the IdP's metadata automatically. For example, updates to the IdP's certificate will not cause problems.

OIDC

• Entity Id
  • Unique identifier for the service. Random identifier is created automatically but it can be changed.
• Grant types
  • Allowd grant types.
    • authorization_code flow: Recommended one.
    • implicit flow: Deprecated.
    • refresh_token: Allows renewal of the expired access token without user login. Refresh token is currently limited to two hours.
  • More information: https://oauth.net/2/grant-types/
• Response types
  • Allowed response types.
    • code is used by the authorization_code flown and choose this if you don't know otherwise. In this case, authorization token and ID token will be received from the separate end point.
    • id_token means that id_token is returned automatically.
    • token means that authorization token is returned automatically (used by implicit flow).
  • More infomration: https://medium.com/@darutk/diagrams-of-all-the-openid-connect-flows-6968e3990660
• OIDC scopes
  • openid scope is required and added automatically.
  • email scope returns email address and profile scope name infomration. These can also be requested separately as claims in the attribute section.
  • offline_access scope is required if you use refresh tokens.
• Applicaiton type
  • web - normal web service.
  • natiivi - login directly from the native app. I.e. mobile application or JavaScript page without backend.
• Subject identifier
  • If specific sub-value is required, specify it here.
  • public is user id based and pairwise is opaque identifier.
• Token endpoint authentication method
  • If you are using client secret authentication, default is usually ok.
• URL for the JSON Web Key Set (jwks_uri)
  • JSON Web Key Set is required if you are using public key authentication.
• JSON Web Key Set
  • RPs JSON Web Key document (jwks) passed as a parameter. Should only be used if the use of jwks_uri is not possible.
• Publish to production servers
  • The service is linked to the login.helsinki.fi production servers, allowing login with any HY user credentials.
  • This requires separate approval from the Shibboleth service administration
• Publish to test servers
  • The service is linked to the login-test.it.helsinki.fi test server.
  • Changes take effect automatically, and you can configure test users in the Test Users section. 
• OIDC product
  • OIDC implementation used by the service.
• Reset client secret
  • When selected, new client secret is generated on save.
• Remove client secret
  • Removes client secret from the product. If you are using public key method.
• Show client secret
  • Shows the client secret for the service.

LDAP

Most of them are self-explanatory; below, you can find further information on some, which may be unclear.

• Does the service use a service account?
  • Almost all services that require information about the user can use the separate service account for finding information. So check this box.
  • If the service requires information other than the login but is certainly unable to use a service account, this can be provided. Fill in the form normally without checking this box, save the form and email an administrator at atk-ldap@helsinki.fi or atk-autentikointi@helsinki.fi.
• Email address and phone number for delivering the service account credentials
  • If you obtain an LDAP username ("service account") for the service, the account and password that are created are delivered via securemail to the email address entered here and the PIN code required for opening the account is sent to the mobile number entered here. So please enter your personal email address used in the helsinki.fi domain as well as your work mobile number so that you can receive the information.
• Publish to production servers
  • The service information is exported to the LDAP2015 system, i.e. once an administrator has approved the service changes it opens the firewall, creates the required credentials and allows access. So you should check this box in almost all instances.

Attributes

The attributes required by the service and a brief reason for using them.

Assigning attributes is always based on need. If you are not sure if an attribute is necessary, the answer is probably no.

LDAP memberOf

One specific attribute worth your consideration is memberOf.

You should select it, if the application gets group information from the memberOf field of the user record instead of trying to find the user in the uniqueMember field of the group record.

Often, you should both select the memberOf attribute to be fetched and list the required groups on the User Groups page. If you are not sure, you might as well do both.

Certificates (SAML only)

Configuring the Service's Certificates.

We strongly recommend that the traffic between the SP and IdP does not use the same certificate as the service's public pages. This especially eases maintenance, as changes to certificates do not need to be coordinated simultaneously. Additionally, from a security perspective, it is beneficial to keep these separate, so that both do not need to be replaced if one becomes compromised.

Since the certificate is delivered to the IdP through this system, it does not need to be verified by a third party. S self-signed certificate can be safely used.

SAML Endpoints (SAML only)

For security reasons, IdP only response to registered service endpoints. In practice, the following are needed:

• AssertionConsumerService urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST is practically always required for authentication.
• SingleLogoutService urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect, if the service supports SLO (Single Log-Out).
  • Note! Ensure that the service logs out if the used SAML application logs out.

It is unnecessary to add others if you do not know what you are doing. With the default setting, for example, Shibboleth SP adds about a dozen of these, of which practically only those two are used.

Almost without exception, only the address needs to be provided for these. A separate response address, sequence number, and default selection are used only in exceptional cases.

Redirect URIs (OIDC only)

Allowed redirect URIs. IdP/OP shows configuration error if requested redirect URI does not match the registered list of allowed URIs.

User Groups (LDAP only)

The LDAP groups required by the service. You can enter the group names one at a time in their short form, e.g. "GRP-A02700-employees".

Contacts

The service contact information, i.e. technical, administrative and support contact. The first two especially are important for administrators.

Admins

On this page, you can manage the persons with access to editing the service information.

You can invite new administrators via email, in which case they will be sent an activation code, which is valid for 30 days.

If IAM group is added to the list of admin groups, all members of that IAM group can manage the service information.

Test Users (SAML and OIDC only)

If publish to test servers is selected in the Technical Attributes section, you can manage test users here.

• Usernames must be unique in the SP-registry.
• By default, test users are limited to the service where they are created. If you administer multiple services, you may allow test users to access other test services where you have admin rights in the SP registry.
  • For test users, you may only set attributes registered to the service they are created. If you are using same test users for multiple services, it may be useful to create one service just to mange test users.
• Changes in attributes are immediate.
• Multiple values may be given by separating values with semicolon.
• Test service does not limit scoped attributes, and you must include scope to value by yourself.
  • Services may limit allowed scopes to ones in the IdP metadata.

View Metadata (SAML only)

Shows service metadata. Validated metadata is used for the production service and unvalidated for the test service.

Login Statistics (SAML and OIDC only)

Lists daily login counts. Updated once a day.

Adding new services to SP-Registry

SAML / OIDC

1. Select "Add a new SAML/OIDC service".
2. Give at least EntityId, name and description and save the form.
   1. SAML ONLY: You may also load SP metadata to import techical information: This must be done when adding a service and cannot be done afterwards.
   2. OBS. Privacy Policy URLs and Application portfolio URLs are required for the production use. For external services, we will also confirm that DPA has been agreed between UH and the service operator.
3. SAML ONLY: Add required certificates and SAML endpoints.
4. OIDC ONLY: Register redirect URIs in the Redirect URIs section.
5. Add required attributes and reasons for them in the Attributes section.
6. Add required contacts in the Contacts section. At least technical contact address is required, administrative contact is also recommended.
7. In the Technical Attributes section, add Publish to production servers or Publish to test servers.
   1. Test servers are updated automatically.
   2. Production services are verified by the IdP administrators before adding them.
8. OIDC ONLY: Technical Attributes
   1. Select grant_types and response_types. Usually authorization_code and code.
   2. Record the client secret from the bottom of the page.

LDAP

1. Select 'Add a new LDAP connection' from the front page.
2. Enter at the minimum the servers used by the service (the DNS names, i.e. names in text format, one per row) and the name of the service in Finnish. Also enter the privacy protection URL and the address of the service in the Application Portfolio. Save the form.
3. On the Technical Attributes page, check at the minimum the 'Publish to production servers' box, because otherwise the service cannot access LDAP2015.
   1. If the service only requires authentication, you can stop here and save.
   2. Otherwise, select at least 'Does the service use a service account?' and fill in the details of the person the service account is delivered to, unless your service really cannot use a separate LDAP identifier to search for the required information. Also check the other options on this page and decide if they are required.
4. Enter the attributes potentially required by the service and the reasons for using them on the Attributes page.
5. Mark the user groups potentially required by the service on the User Groups page.
6. Enter the details of the contact persons of the service on the Contacts page.
7. An administrator will separately verify the services published to LDAP2015.

Removing a service from SP-Registry and the production servers

1. Select the "Technical attributes" page of the service.
2. Select the service to be removed from the front page.
3. Deselect "Publish to production servers".
4. Save the changes at the end of the page.
5. Once the changes have been validated, you can also remove the service from SP Registry.
   1. There will be a removal link at the end of the Summary page of the service once the service has been removed from the production servers and the changes have been validated.