Resource states

At any given moment, a resource has a state, that changes through its lifecycle.

There are two models for resources lifecycle:

• A simplified model, to be used by services integrated with the Authorization Service / Resource Portal.
• A detailed model, used internally by the Authorization Service / Resource Portal. Other services can use this model as well, but it probably exposes more details than needed.

Simplified resource states

Resources provided by the Authorization Service API expose a state property, which can assume the values in the diagram below.
The state property combines the internalState and disabled properties (explained in the "Detailed resource states" section below) into a single property that is more suitable for services integration, as you will not need to block or allow access to your resources based on some complex logic, but will only need to react to state changes.

The individual resource states are:

• Created (optional, if your service needs it): the resource was created, and some initialization is required for the resource to be operational. For example, the Service Desk might need to communicate the initial password of a user's computing account to the account owner.
• Active: the resource is fully functional.
• Blocked: the resource is blocked, and cannot be accessed. For example, a computing account might be unable to authenticate, a website might no longer be accessible and so on. Unless the resource owner gets ownership rights again, at some point in the future the resource will be archived (if the service supports it) and finally deleted.
• Archived (optional, if your service supports it): the resource cannot be accessed, and it cannot be automatically recovered. The resource can still be recovered with some manual operation. If the resource is not recovered, at some point in the future the resource will be deleted.
• Deleted: the resource is deleted, and cannot be recovered in any way. Deletion is being implemented as an explicit state so that integrated services do not risk deleting resources by mistake e.g. because of missing data from the API. Deleted resources will actually be deleted from the internal database at some point in the future.

Important: the name of Archived and Deleted resources is changed to a unique identifier, to avoid keeping their name reserved, which could be a problem e.g. if someone needs to create a group with the same name of a group that was archived.

Detailed resource states

Resources provided by the Authorization Service API expose an internalState property, which can assume the values in the diagram below.

The individual resource states are:

• Created (optional, if your service needs it): the resource was created, and some initialization is required for the resource to be operational. For example, the Service Desk might need to communicate the initial password of a user's computing account to the account owner.
• Active: the resource is fully functional.
• Action Required: the resource's previous owner no longer had the privileges required to own the resource, so the resource was automatically reassigned to their supervisor. The resource is still functional, but the new owner needs to take an explicit action on it. The possible actions are:
• Assign the resource to a Resource Group.
• Archive or deleting it.
• Inactive: the resource is functional, but has entered a grace period because its owner does no longer have the rights to own it. Unless the resource owner gets ownership rights again, at some point in the future (determined by the policies defined for the resource type) the resource will be blocked, then archived (if the service supports it) and finally deleted.
• Blocked: the resource is blocked, and cannot be accessed. For example, a computing account might be unable to authenticate, a website might no longer be accessible and so on. Unless the resource owner gets ownership rights again, at some point in the future the resource will be archived (if the service supports it) and finally deleted.
• Archived (optional, if your service supports it): the resource cannot be accessed, and it cannot be automatically recovered. The resource can still be recovered with some manual operation. If the resource is not recovered, at some point in the future the resource will be deleted.
• Deleted: the resource is deleted, and cannot be recovered in any way. Deletion is being implemented as an explicit state so that integrated services do not risk deleting resources by mistake e.g. because of missing data from the API. Deleted resources will actually be deleted from the internal database at some point in the future.

Even when resources are in state for which they are expected to be accessible, they might still be explicitly disabled, e.g. for security reasons. This is exposed through the disabled property.

Mapping internalState and disabled to state

Internal state	Disabled	State
Created	false	Created
Created	true	Blocked
Active	false	Active
Active	true	Blocked
Pending Action	false	Active
Pending Action	true	Blocked
Inactive	false	Active
Inactive	true	Blocked
Blocked	*	Blocked
Archived	*	Archived
Deleted	*	Deleted

Grace periods

For each resource type it manages, a service can define:

• Blocking grace period: number of days before a resource will be blocked, from the moment it becomes inactive. If not specified, the service does not support blocking.
• Archive grace period: number of days before a resource will be archived, from the moment it becomes inactive. If not specified, the application does not support archiving.
• Delete grace period: number of days before a resource will be deleted, from the moment it becomes inactive. If not specified, the application does not support deleting.