3. Deep custom actions

Custom Actions for Authorization

Sometimes in the project some actions or customizations are required in terms of workflows, or features.

Mainly, ChustaSoft Authorization provide some mechanisms:

• External Providers configuration
• Custom action after user creation
• Default users loading at Startup

External Providers configuration

Configuration allows also to configure External Providers:

1. Microsoft
2. Google

Check here for the configuration by appSettings

Check here for the configuration using builder. Commented block code on line ~ 50

Custom action after user creation

This type of action is intended to perform cascade actions after creating a user, based on a Event Driven behaviour. To do this, a specific contract provided by the Abstractions package must be implemented, and add it during the configuration of the tool in Startup:

1. Implement IUserCreated in a class, this is the required behaviour for this contract:

namespace ChustaSoft.Tools.Authorization
{
    public interface IUserCreated
    {

        void DoAfter(object sender, UserEventArgs e);

    }
}

2. Add this method during the ConfigureServices on startup:

   services.RegisterAuthorization<CustomUser, CustomRole>(_configuration, "d5ab5e3f5799445fb9f68d1fcdda3b9f")
      .WithUserCreatedAction<CustomUser, CustomUserAction>() // Here is added the custom implementation
      .WithSqlServerProvider<AuthCustomContext, CustomUser, CustomRole>("fullConnectionString");

This implementation will be reached once a user is succesfully created in the DB. Inside, UserEventArgs provide information related to the user created:

• UserId: The Guid of the user created raising the event
• Parameters: A dictionary containing parameters. Those parameters could also be sent from a client, and then re-thrown to the client API. Other parameters will be automatically added, such as Confirmation tokens of Email and Phone, allowing the client project to manage this confirmation with some Views, Email, etc...

In relation to this possibility of sending parameters from Client UI > Auhtorization > Client Api, Credentials object could deserialize a parameters dictionary similar than the UserEventArgs object. This parameters will be re-thrown to the Client Api thrugh this IUserCreated. Also, frontend will receive during registration confirmation tokens in case of Confirmation required is configured on AuthorizationSettings

Default users loading at Startup

This functionality is designed to define default users who will always be in the system. Any type of user can be configured, although it is especially recommended to define system users and admins within the project, so that it performs all the load in the system, assigning roles and auto confirming said accounts.

To take advantage of this functionality, will be required to extend the configuration at Configure method on startup

   app.ConfigureAuthorization(env, serviceProvider, "IdentityPolicy")
      .SetupDatabase<AuthCustomContext, CustomUser, CustomRole>()
      .DefaultUsers(ub =>  // Here is possible to add through IAuthorizationBuilder default users, using a builder inside, roles can be also assigned.
      {
         ub.Add("SYSTEM", "Sys.1234").WithFullAccess();
         ub.Add("ADMIN", "Admn.1234").WithRole("Admin").WithFullAccess();
      });

Once added, at project startup those users will be checked in order to create or update if neccesary.