Unit4 Identity Services Portal

Unit4 Identity Services can be administered with the U4IDS Portal. It is used to log in to and configure a specific U4IDS installation through the public U4IDS Api.

The Portal allows you to configure:

Access

In order to log in to a specific U4IDS service you first need to be a valid user for the Portal Admin Tenant specified in the configuration or the specific Tenant you are logging in to. An Access Management service needs to be configured for the U4IDS service in order to use the Portal. When a user is authenticated in the Portal but have no access in Access Management, an access request is sent and an administrator could either accept or reject the request. The Access Management service provides us with three basic Roles. Owner, Contributor and Reader. The Owner have complete access and lets you also administer other users in the system. The Contributor have complete access but can't administer users. The Reader can off course only read.

See https://thehub.unit4.com/docs/access-management for more information.

Portal Admin

When you log in to the portal you choose the configured IDS that you want to administer and then choose what Tenant (organization) you want to log in to. If you log in to the "Administrator Tenant" you will have access to all Scopes, Clients and Tenants in that IDS instance. You can also choose what Tenants people should be able to log in to and invite users that should administer them.

Tenant Admin

If you log in to a specific Tenant and have the Owner role you will be a Tenant administrator and will be able to add users and clients to this Tenant. If you log in as a Contributor you will be able to add clients to the Tenant and if you log in as a Reader you can only see Tenant specific information.

As soon as you try to log in to something you dont have access to you will be prompted to send an access request with your preferred role (Owner, Contributor, Reader) It is up to the Administrators (Owners) to either Accept or Deny your access request.

Actions

When you choose Tenants, Scopes, Clients or Users in the left menu you will get a list of all items that you have access to. If you select an item in the list, you will see the details of that item and buttons for the actions you can take on it. The complete list of actions consists of Edit, Delete, History, Secrets and Back but it can look a little different depending on that type of item it is or the type of access you have.

Clients

In the portal the Clients are divided into Machine To Machine clients that will use the Client Credentials flow, Proof Key for Code Exchange Flow or PKCE (pronounced pixie) type client that is the recommended choice for any user centric login. Implicit Clients that will use the Implicit Flow, Hybrid Clients that can use the Hybrid or the Authorization code flows and Custom clients that use Custom flow with either user-impersonation or claims-upgrade as Allowed Custom Grant Type. All client types except for Implicit clients and PKCE clients will create secrets by default. You can always create a new secret using the Secret action in the list, but not for Implicit clients. If you dont create a secret for a PKCE client you dont need to provide one but as soon as one is created it needs to be provided by the connecting client.

You can view deleted clients from a button above the client list.

See more on how to Create and configure Clients here Configure Clients

Scopes

Scopes can also have secrets, but they are never created by default. You need to use the action in the list to add a secret to a Scope. There will be a * after all scopes that are in use. Those cannot be deleted.

You can also choose to add localized texts for a scope. The localized texts will not be used in the Portal but will be shown to the user in for example Consent Screens. There is an import and an export button for the localized texts. They can be used to export the localized texts that you have created or import already created texts for a scope. The name of the file must be the same as the scope name and the file format must be JSon. After importing localized texts you need to save to persist them in the database.

This is the schema for the json file.

{
  "definitions": {},
  "$schema": "http://json-schema.org/draft-07/schema#",
  "$id": "http://example.com/root.json",
  "type": "array",
  "title": "The Root Schema",
  "items": {
    "$id": "#/items",
    "type": "object",
    "title": "The Items Schema",
    "required": [
      "description",
      "displayName",
      "language"
    ],
    "properties": {
      "description": {
        "$id": "#/items/properties/description",
        "type": "string",
        "title": "The Description Schema",
        "examples": [
          "English"
        ],
      },
      "displayName": {
        "$id": "#/items/properties/displayName",
        "type": "string",
        "title": "The Displayname Schema",
        "examples": [
          "Test title scope"
        ],
      },
      "language": {
        "$id": "#/items/properties/language",
        "type": "string",
        "title": "The Language Schema",
        "examples": [
          "en"
        ],
      }
    }
  }
}

You can view deleted scopes from a button above the scope list.

See more on how to Create and configure Scopes here Configure Scopes

Tenants

You can choose to make a tenant "login Tenant". That means that you will be able to log in to the portal and only administer this tenant.

A Portal Administrator can either create users for this Tenant or Invite users and accept their Access requests.

One Tenant can have multiple IDPs. One must be the default IDP. You can never delete the default IDP but you can change which IDP is the default. Tenants do not have the secrets action.

You can view deleted Tenants from a button above the Tenant list.

See more on how to Create and configure Tenants here Configure Tenants

Users

Users in the Portal could be added manually or because of a user trying to log in to a specific IDS Service through the Portal. When a user that can be authenticated by the IDS, but do not have rights in Access Management tries to log in a new user will be created with default role Reader and state pending. Then when users with the Owner role opens the user list, they will see the new users with status pending and Approve and Reject buttons after and can take action. To add a completely new user you choose the Create new User button over the Users list.

You can also choose to invite users. Then you only need their email address, and everything else will be fetched from their login attempt.

If you choose a role for the invite the user will be preapproved. The invite for the user will contain a code that can be used to gain access to the portal as long as the users email claim is consistent with the email from the invite. If you dont choose a role in the invite the user needs to select the chosen level of access (Owner, Contributor, Reader). An administrator then needs to approve the request before they can log in. All users must be valid users in the IDP for the Tenant that they are trying to log in to. All users in the list could be edited or deleted in the action menu. So, you dont need to reject a user if you dont agree with the chosen level of access. You can just change it and approve. If you use the approve or reject button on user details AND if a SendGrid:EmailConfirmationService have been set up the user will get an email with the outcome of the request.

You can view deleted Users from a button above the Users list.

IDS Instances

If you have the owner role, you are allowed to add, edit and delete the IDS Instances that the portal can access. When you choose the IDS Instances you will see a list of all the connected IDS Instances, including the main instance that is configured in the Application Settings for the Portal Web app in Azure. These instances could be edited or deleted, except for the Main instance that only can be changed in the Application Settings.

You can also start the guide to connect to IDS.

In the first step you choose a name to identity the IDS Instance and then add the base Uri to the IDS.

If the base uri is found, the discovery endpoint will be checked for information about the IDS. If it contains the Tenant id then it will be defaulted for the Tenant ID field. If there is a hybrid client created for the portal you can just enter the client id and secret here. But if that is not done you can choose to create it here. You then need a client credentials client with the u4ids-admin scope. Typically, the short-lived client that is created when you deploy a new ids. If you enter these credentials the client will be created for you, and its secret will be saved.

The last step depends on if you are using basic or bearer authentication. If you are using basic, you must enter the user name and password and if you are using bearer you could either choose to enter the path to an Access management service connected to this IDS or you could use an external role. The Access management Uri can also be defaulted from the IDS. Remember to add the version to it.

After you have pressed Create to add the configuration, you should be able to log out and choose it in the IDS dropdown in the login screen.

Sessions

When you log in you will get a session that keeps the information from the login. When that session expires you will get a message that you don't have access and you will have to log in again.