A solution consists of the following:
Solution definition.
This is just the name, and is defined by the Web Development team to ensure no name clashes.Permission definitions.
Permissions are used when the user interface calls APIs provided by a solution. Typically, these would be CRUD (create, read, update, delete) operations (e.g.spire:create:user) but any permission requirement can be accommodated.
So, each API provided by a solution - if it is not a public API - needs to have one or more permissions associated with it to control who can call it.
Permissions, when represented in the authorization token, can target the subscription or a resource. Targetting permissions at a resource is useful when granting access to a specific item within a subscription. An example might be granting visibility of the conformance runs for a specific device under test.Seat definitions.
A seat within SPIRE is the mechanism for granting permissions to a user. As such, a seat definition controls which permissions can be granted to a user. A seat definition can be considered to be similar to a role or a persona. It should be seen preferable to have definitions that group appropriate permissions rather than have one definition and force the subscription administrator to grant or remove individual permissions.
For example, ONELab has ONELab Developer and ONELab Viewer. When a seat is granted to a user, two choices are made:Whether to grant all of the permissions or a selection of them
Whether to target the permissions at the subscription, or one or more resources.
Plan definition.
A subscription in SPIRE is created from a selected plan. A plan defines which seat definitions are available, and whether or not there are any limits on how many of each seat definition can be granted. Plans can be turned into user subscriptions or organization subscriptions.