Enduser Management Solutions - Azure Active Directory

State change: Various events can trigger state changes in such a scenario. Targeting users with marketing content usually requires consent by the user. Expiry or explicit withdrawal must be reflected in those systems.

Business partners as endusers: Business partners have to go through a much more complicated process before being verified. This might also include backoffice activities that trigger further state changes. Leaving the business or closing of business triggers state changes in the associated users.

Guest user: To maximize online-business users should also allowed to do business although they may not yet fully registered in the system.

API: Systems should have a clear defined API to shield calling applications from implementation details and allowing changing of underlying platform. An API also simplifies versioning.

Integration: Certain aspects such as authentication might split across multiple systems. Systems have to communicate in such a scenario and might have to be able to receive signals to move forward in the processing flow.

Data modeling: Complex scenarios have a much more complex data model which might include arbitrary attributes and own custom entities.

Implementation (Testing): Testing is a challenge since the tested functionality requires user interaction.

Implementation (Provisioning): Automatic deployment pipelines should be preferred. The challenge might rise from the fact that the developers reside in a different organizational boundary than the endusers of the application.

Operations (Monitoring): The user interactions must be monitored end-to-end across enduser management and the pplication. This might be challenging if enduser management is factored out in a separate service.

API: A clear definition of the interfaces would preferable. This also allows to address versioning and abstraction of the underlying enduser management implementation.

Flows: Flows refer to a sequence of actions mainly related to authorization and authentication. The flows are highly asyncronous due to possible blocking enduser interaction. E.g. if the user has to confirm his identity with an EMail verification link.

External: Bidrectional communication is required if functionality is split across systems. E.g. if the backoffice approval is factored out in a different systems that requires adjusting the state of the enduser.

Custom logic: It must be possible to incorporate custom logic e.g. to get additional data such as loyalty id.

Data store: Endusers state must be persisted along with all asscociated information.

Scheduling: Consent by the enduser might be limited to a certain expiry date. Expiry usually requires state changes of the enduser in the enduser management service.

On behalf of: Especially if business partners as endusers are involved it is common that others do things on behalf of others. E.g. if the owner (=enduser) of a business partner organization invites employees.

Access Reviews: Endusers you have been granted access might not be there anymore. E.g. because they have left their home organization. In that case system support is helpful that allows to determine which users are still active.

Own entities: The features only support custom attributes but no own entities.

Separate tenant: AAD B2C comes with an own tenant that differs from the corporate one where the provisioning services might live. Azure DevOps pipelines don’t work if you use custom policies.

Bidirectional communication: Receiving messages in a publish/ subscribe pattern might not be directly supported.

APIs: AAD comes with its defined endpoints. It is not possible to introduce custom APIs.

Multiple organizations: Especially when endusers can be business partners users might be associated with multiple organizations. A tenant can serve as organization. However, a tenant is a heavyweight construct and moving endusers between tenants is not as easy as a data store update.

Azure AD B2C - Session managed by Azure AD B2C

Federated identity provider - Session managed by the identity provider, for example Facebook, Salesforce, or Microsoft account

Application - Session managed by the web, mobile, or single page application

Implementation (Testing): User flows can be tested separatly without being incorporated into an application. No additional support beyond that feature exists.

Implementation (Provisioning): Automatic deployment pipelines should be preferred. The challenge might rise from the fact that the developers reside in a different organizational boundary than the endusers of the application.

Operations (Monitoring): Azure provides Azure Monitor for monitoring the enduser management service from the application perspective. Monitoring the AAD service from infrastructure perspective is more difficult.