User Self-Service Portal

A Self-Service Portal application is a browser-based single page application (SPA) secured under the hood by the usage of the Token Handler pattern to protect access tokens. It uses these GraphQL APIs to communicate with the Curity Identity Server:

• User Management GraphQL API from the linked User Management profile - used to manage user accounts, e.g. view and edit personal information, manage MFA settings.
• Granted Authorization GraphQL API from the linked Token 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 and related data.

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.

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 an “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 multifactor 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 defined 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, the Self-Service Authorization Manager allows fine-tuning these settings.

Account Deletion#

The Self-Service Portal application can be configured to allow users to delete their own accounts. Due to the non-reversible consequences of this operation, account deletion is not enabled by default, even when the Self-Service Portal application is created with edit permissions.

Enabling Account Deletion#

To enable users to delete their own accounts:

1. Enable the delete operation: In the Self-Service Portal application configuration, navigate to the User Management Access Control Rules section and explicitly enable the “delete” operation for the “Account” resource.
2. Alternative GraphQL configuration: When configuring the Self-Service Authorization Manager directly in GraphQL-mode, add the deleteAccountById GraphQL mutation to the list of allowed mutations.

What Gets Deleted#

Account deletion is performed via the deleteAccountById GraphQL mutation, which synchronously deletes:

• The user account itself
• Associated devices
• Associated credentials
• Account links

To also revoke OAuth delegations and dynamically registered clients associated with the deleted account, additional configuration is required on the Token Profile:

1. Navigate to the Token Profile settings.
2. Enable the Event-handling section.
3. Set both of the following options:
   • revoke-delegations-on-account-deletion - revokes all delegations associated with the account.
   • revoke-dynamic-clients-on-account-deletion - removes dynamically registered OAuth clients (DCR clients) owned by the account. Note that delegation and dynamic client revocation will be done asynchronously.

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.