How to evolve authorization in your application lifecycle

Evolving resources and application roles

Backwards-compatible migration steps to change a resource or an application role are required to transition access to an API, UI, or domain object.

By changing or restructuring access to resources, organization roles may have more or less privileges than originally intended. Proposal to successfully migrate a restricted API, UI, or domain object from resource A to B without problems:

Assume n is the software version before changing resources.

In application version n+1
1. Introduce new resource B (registration, authorization decisions).
2. Adapt application role privileges.
3. Allow access to an API, UI, or domain object by either new resource B or old resource A.
4. Document that an authorized person has to update all organization roles that currently allow access by resource A to also contain resource B before the next version upgrade.
In application version n+2
1. Allow access only by resource B (removing resource A from that API, UI, or domain object).
2. Remove resource A (as appropriate).
3. Document that resource A now ceases to function (if used in organization roles).
4. If any resources or roles are not used at all anymore, remove them in a setup step or at application startup — don’t just leave them "lying around".

Termination of service

In order to terminate an application, these steps are currently recommended:

Delete all the application’s roles and resources.
This ensures that the application is not available to anyone any more as all references in contracts are removed as a result.
Delete the application.