Self-Service Portal

The Self-Service Portal application plugin is used to create a browser-based application that allows users to manage their accounts, e.g. view and edit their personal information, manage multi-factor authentication (MFA) settings, and manage authorizations granted to third-party applications. It is secure, as it uses the Token Handler pattern under the hood to protect access tokens. A Self-Service Portal application is a browser-based single page application (SPA) that uses these GraphQL APIs to communicate with the Curity Identity Server:

  • GraphQL API available on the um-graphql-api endpoint from the linked User Management profile - used to manage user accounts, e.g. view and edit personal information, manage MFA settings.
  • GraphQL API available on the oauth-granted-authorization-graphql-api endpoint from the linked OAuth profile - used to manage authorizations granted to third-party applications, e.g. view and revoke authorizations granted to applications.

The API access is authorized using the Self-Service Authorization Manager, which ensures that users can only access their own accounts.

Creating a Self-Service Portal Application

Self-Service Portal applications are configured in an Application service profile, more specifically on the applications list. The following two figures illustrate listing and adding a Self-Service Portal application.

../../_images/application-list.png

Fig. 45 Listing all applications.

../../_images/self-service-portal-create.png

Fig. 46 Adding a Self-Service Portal application.

Configuring a Self-Service Portal Application

Configuring a Self-Service Portal application is a fairly complex task, as it requires different components in the system to work together (e.g. profiles with GraphQL APIs, Authorization Manager, scopes and claims). To help with that there’s a setup wizard that guides administrators through the configuration steps. The wizard is divided into four steps:

  1. Collecting all the necessary information to create a fully functional Self-Service Portal application.
  2. Show a summary of what will be created and allow administrators to review the configuration.
  3. Deploying required endpoints (if necessary), e.g. the um-graphql-api or the oauth-granted-authorization-graphql-api endpoint.
  4. Create the Self-Service Portal application and all the necessary resources.
../../_images/configure-self-service-portal.png

Fig. 47 1st step to configure a Self-Service Portal application.

In the first step of the setup wizard, you are asked to provide the following information:

  • Prefix - by default, it is set to the application ID, but it can be customized. It has to be unique amongst the portal applications to ensure that all created resources will have unique IDs or names.
  • HTTP Client - the HTTP client that will be used to communicate with the linked OAuth profile (e.g. to get tokens).
  • Allowed Authenticators - the list of authenticators (from the linked Authentication profile) that can be used by users to log in to the Self-Service Portal. If no authenticators are selected, all authenticators from the linked Authentication profile will be available to use.
  • Enable Granted Authorization Management - whether the users should be able to manage authorizations they’ve granted to 3rd party applications. When enabled, there will be a “Apps and Services” section available in the portal.
  • Enable User Management - whether the users should be able to manage their own accounts. If enabled, users will be able to view and edit their account details, such as address, name, email, phone numbers, passwords, etc. Additional settings are available to control the user management experience:
    • User Management Profile - the user management profile that will be used to manage user accounts. The selected user management profile must be configured to use an Account Manager. Also all authenticators/actions that are being configured here must use the same Account Manager so that it is ensured that the user accounts are updated consistently.
    • Manage Opt-In MFA - whether to enable Opt-In MFA action management. The configured Opt-In MFA action that will be used by the Self-Service Portal to manage multi-factor authentication (MFA) settings. The action will be set on the linked user management profile (in the Account Settings section). The same action should be configured in the authenticators used by users to log in to the Self-Service Portal, if MFA is desired.
    • Manage TOTP - whether to enable TOTP device management. The configured TOTP authenticator that will be used by the Self-Service Portal to manage TOTP devices. Devices registered via the Self-Service Portal will be usable by this authenticator. The authenticator will be set on the linked user management profile (in the Account Settings section)
    • Manage Passkeys - whether to enable Passkeys management. The configured Passkeys authenticator will be used by the Self-Service Portal to manage passkey credentials. Passkeys registered via the Self-Service Portal will be usable by this authenticator. The authenticator will be set on the linked user management profile (in the Account Settings section).
  • Allow Editing - if enabled, users will be able to edit their own accounts. Otherwise, Self-Service Portal will allow users to only view their accounts. The access control can be further fine-tuned after the application is created. See the Authorization section below.
  • Account Manager - the Account Manager to be set in the Claims provider that will be created by the Self-Service Portal wizard. This Account Manager will be used to set the account_id claim in access tokens used by the Self-Service Portal. In case the User Management Profile is set above, the Account Manager set in the user management profile will be used to ensure accounts are resolved correctly.

The summary of all resources that will be created is shown in the second step of the wizard.

Once a Self-Service Portal application is created, it can be further customized by editing the application. Notable settings include authorization and look & feel customization.

Authorization

When a Self-Service Portal application is created, a unique instance of Self-Service Authorization manager is created and used. This authorization manager ensures that users can only access their own accounts. Additionally it controls which sections of the Self-Service Portal are available to users based on the configuration entered in the first step of the setup wizard. For example, it’s possible to disallow changing phone numbers, and this results not only in the proper authorization for the GraphQL APIs being used, but also in the Self-Service Portal application disabling/hiding the phone number update section in the UI. This configuration can be further customized by editing the application in the edit modal’s Authorization Manager Configuration section. Also Self-Service Authorization Manager provides more details on how to fine-tune the Self-Service authorization manager.

Customizing Look & Feel

The Self-Service Portal web application can be customized to match the look and feel of an organization. A custom theme can be created under the System -> Look And Feel section. See Customize branding per Application for more details. Once a custom theme is created, it can be selected in the Self-Service Portal application edit modal (Template Area and Themes).

Accessing Self-Service Portal Web Application

After a Self-Service Portal application is created, it can be accessed on this URL: <base-url>/<application-service-anonymous-endpoint>/<application-id>

Other Considerations

  • It is recommended to set up the login pipeline to a Self-Service Portal application in a way that prevents users with inactive accounts from logging in. Such users would not be able to access their accounts and manage them.
  • It is strongly recommended to create a single Self-Service Portal application per Application Service profile. Multiple Self-Service Portal applications in a single profile can lead to unexpected behavior and issues (in case they are opened in the same browser). If multiple Self-Service Portal applications are created within different profiles they should be served from different domains.