User Account

The user account (UserAccount entity) represents a business-level abstraction of a user.

Difference from IUserInfoAccessor.User

It's important not to confuse the user account with the User property accessible via the IUserInfoAccessor service:

• The IUserInfoAccessor.User property contains authentication-related data, provided by the authentication server.
• The UserAccount represents the business logic layer's user data, used to manage domain-specific details such as roles, permissions, and profile settings.

The Identifier property of the IUserInfoAccessor.User corresponds to the Login property in the UserAccount entity.

Getting the current user account

To get the current user account, use the GetCurrentUserAccountAsync() method from the IUserAccountAccessor service.

/// <summary>
/// Represents the implementation of the <see cref="IMyServerMethod"/> interface.
/// </summary>
public class MyServerMethod : IMyServerMethod
{
    private readonly IUserAccountAccessor _userAccountAccessor;

    /// <summary>
    /// Initializes a new instance of the <see cref="MyServerMethod"/> class.
    /// </summary>
    /// <param name="userAccountAccessor">User account accessor.</param>
    public MyServerMethod(IUserAccountAccessor userAccountAccessor)
    {
        _userAccountAccessor = userAccountAccessor;
    }

    /// <inheritdoc/>
    public async Task Execute()
    {
        UserAccount? userAccount = await _userAccountAccessor.GetCurrentUserAccountAsync();
    }
}

Using the IUserAccountAccessor service is preferable over directly using the IUserAccountRepository repository. This is because the service caches the user account, reducing the need for repeated database queries whenever the user account is required. The cache is scoped to the current request, ensuring that the user account is up-to-date and consistent throughout the request's lifecycle. For example, it creates one instance for each HTTP request, but it uses the same instance in the other calls within the same web request.

User type

Users can either be clients or publishers:

• Client: Can view and modify only client-type users.
• Publisher: Can view and modify all users.

This property can used to control access to specific features within the application. For example, you can condition access using the Authorization condition of a function. Here's an example implementation:

Transversals.Business.Domain.Entities.UserAccount? userAccount = await
  // Get the UserAccountAccessor service from the service provider
  ((Transversals.Business.UserPermissions.Application.Services.IUserAccountAccessor)ServiceProvider.GetService(typeof(Transversals.Business.UserPermissions.Application.Services.IUserAccountAccessor)))
  // Get the current user account from the cache
  .GetCurrentUserAccountAsync();
// Using the user type to authorize or deny access to a function
return userAccount?.Type == Transversals.Business.Domain.Enums.UserType.Publisher;

Service account

A service account is a special type of user account designed for machine-to-machine authentication using the OAuth2 Client Credentials flow. Instead of a login email, a service account is identified by a ClientId, which acts as the account's Login property.

Service accounts follow the same principles as regular user accounts: they can be assigned roles and permissions, and they carry a user type (Client or Publisher) that controls their level of access within the application.

To enable Client Credentials authentication for an application, a service account must first be created in the user management screen or via DefaultUserAccountLogin in the cluster configuration. Once created, the consuming application authenticates against the authorization server using its ClientId and ClientSecret. The resulting token is then recognized by the framework, which resolves the corresponding UserAccount — including its roles and permissions — just as it would for a regular user session.

Depending on your authentication setup, additional configuration may be required to support the Client Credentials flow:

• ServiceAccountClaimNames: Specifies which JWT claims the framework should inspect to retrieve the service account identifier. This is necessary when your identity provider uses a non-default claim (e.g., appid for Azure AD service principals).
• AdditionalJwtAuthorities: Required when the tokens issued for service accounts come from a different identity provider than the one used for regular users. This allows the framework to validate tokens from multiple authorities simultaneously.

For more information on how to set up the Client Credentials flow with your identity provider, refer to the official documentation:

• Azure AD B2C — Client credentials grant flow
• Microsoft Entra External ID — OAuth 2.0 client credentials flow

User display language

The DisplayCultureCode property of the UserAccount entity controls the application's display language.

The user account edit screen (UserAccountUI UI view) allows administrator to select a display language for a specific user, including its culture. For example, selecting French (Canada) will set the DisplayCultureCode to fr-CA (fr being the language code and CA the culture code).

If the selected language is supported, the application will be displayed in that language. Otherwise, it defaults to the predefined default language.

Culture settings also affect the date format, ensuring that dates are displayed in a familiar and understandable format.

For more information, refer to this article: Customize application cultures.