Persona based access control

One of the design goals of an access control system be it RBAC, ABAC or raw entitlements based is that the user interface should only display options that are actually available to the user. The purpose of this is of course to create a smoother user experience especially for occasional users that don't need complex functionality to perform their tasks. In RBAC based system the classical example is to hide or grey out buttons based on what roles the user has.

This works well if there is a base UI that all users of a specific category needs and a specific user does not belong to more than one category. These assumptions are unfortunately not always correct.

If you for example look at the health payer space a single physical user can take a number of different personas. The same person could be a consumer of health services ("member"), work as a health insurance broker ("broker") or for a health service provider doing billing or similar work ("provider"). It is even common that the same person works for multiple providers but may need a completely different interface for each provider as the line of business is sufficiently different. The same person may code dental claims on Monday and GP claims for her other employer on Tuesday through Friday.

You could of course implement this use case by building a different portal for each type of user with different URLs and then federate the identities between the portals but that gets expensive and very complex both from a developer as well as a user standpoint. You could also implement the logic in custom code but that gets expensive.

Another option is to use some form of persona based access control. There are a couple of different approaches with one being using ABAC and XACML and the other of establishing the persona as a concept in the authorization model.

SecurIT is hosting a webinar on using their Trustbuilder product to implement persona based access control and if you are interested in PBAC I strongly recommend registering.