Resources lifecycle and eligibility integration

Resource Portal

The Resource Portal will provide users with a unified view of their services subscription status and the resources they own, like in the following mockups.

Subscriptions view

Users can see to which services they are subscribed, for which services they are eligible and not eligible.

The subscription status of a user to a service is determined through a set of Roles mapped to Groups. See the Community Edition section for more details.
If a service defines a self-subscription group, eligible users will see an option to subscribe to the service if they are eligible, and to unsubscribed if they are subscribed.

Resources View

Users can see the resources they own, grouped by Resource Group and resource type.

Lifecycle operations, such as archiving or deleting the resource or assigning it to another Resource Group, can be performed from the Resource Portal itself.

A link to the resource-specific website, managed by the service managers, will take users to a page where they can perform service-specific operations.

Please note that the Resource Portal will not manage the creation of new resources.
See the Enterprise Edition section for more details.

Integration models

Other services can be integrated with the Authorization Service in two ways.

Community Edition

This is a lighter integration model, suitable for services that do not need to track the lifecycle of individual resources and only need to determine if a user is subscribed or not to the service.

The new resources portal will show users if they are subscribed, and allow them to subscribe if they are eligible to subscribe to the service; if a user is not eligible, this is clearly shown in the portal.

The Authorization Service maintains the list of users subscribed to the service.
Integrated services can get users data either:

• Calling the Authorization Service API (pull)
• Consistency enforced on the integrated service's side
• Providing a CRUD REST API that will be called by the Authorization Service (push)
• Consistency enforced on the Authorization service's side

Eligibility is managed by defining, for each integrated service, the following roles:

• Eligible: determines if a user is eligible for the service, i.e. if they are allowed to subscribe to the service on demand. If not specifed, every user is considerd to be eligible by default.
• Subscribed: determines if a user is subscribed to the service, i.e. if they are allowed to access the service. If not specifed, every eligible user is considered to be subscribed by default.
• Denied: determines if a user is explicitly denied access to the service. The "denied" logic takes precedence over all other roles. If not specifed, the service enforces no deny mechanism.

A service can also define a self subscription group, so that eligible users can subscribe to the service (optionally with the approval of a service manager), and an administrators role, that will allow service managers to visualize and manage all resources belonging to the service for any user.

Enterprise Edition

This is a tighter integration model, suitable for services that need to track both the lifecycles of individual computing resources and subscriptions.

All the Community features are available.
The Authorization Service also tracks ownership of individual resources, and allows users to view the resources they own and manage their ownership. Specific resources (e.g. Openstack projects, Oracle accounts, websites) should be requested or created by end users via dedicated portals.

Services can poll the Resource Portal for individual resource states.