Hierarchical multi-tenant - problem when using the Move feature means some logged-in users will have the wrong DataKey

[JonPSmith]

There is a problem when using the hierarchical Move feature with the current arrangement. The problem comes that logged-in users that are linked to tenants that have been moved will have the wrong DataKey. This could cause lots of problems.

The best solution is remove the DataKey claim and replace it with the tenant primary key (tenantId) in the claims. The tenantId doesn’t change with a move and you then use the tenantId to get the DataKey. The down side is getting the DataKey adds an extra database access to get the Parentkey from the tenant, which when combined with the tenantId will create the correct DataKey. To do this you would create a different IGetDataKeyFromUser which contains a lazy DataKey which accesses the AuthP tenant to get the DataKey.

NOTE: This is a breaking change, and needs a way to transition an already running application

[JonPSmith]

While replacing the DataKey with the tenant primary key (tenantId) is one way around this problem, the the 2.3.0 version of this library provides a non-breaking approach. This two features in version 2.3.0, they are

• Add a IRegisterStateChangeEvent service to detect a change to a DataKey and update the LastUpdatedUtc in a global storage.
• Add a LastUpdatedUtc claim into the user and use the cookie OnValidatePrincipal event to update a user's claims if the LastUpdatedUtc claim is older then the global storage LastUpdatedUtc

This approach has some (small) downsides:

• You need a global storage system to hold the global LastUpdatedUtc. However, a simple solution is to create a text file in the wwwroot directory, which is fairly fast (but I assume Redis would be quicker).
• There is a small performance cost (< .1 ms if using global text file) on every HTTP request.
• There is a small possibility that a user with the original DataKey is just about access the data, but is stopped by the Move transaction. Once the Move transaction finishes the user that was held up by the transaction will access the database with their original DataKey, which is now incorrect. Possible solution to the small possibility is to redirect users to a "please wait" page for a few seconds prior tothe Move starting.