Skip to content

Resources lifecycle and eligibility integration

Resource Portal

The Resource Portal provides users with a unified view of:

  • Their eligibility to services, i.e. which service categories (e.g. Database Services) they are allowed to access based on their status.
  • Their subscriptions to applications, i.e. which applications they are subscribed to and can access. In the Database Services example, a user could be subscribed to the DB On Demand application but not to Oracle databases because they never requested access to the Oracle application. A user can request access to an application only if they are eligible for the corresponding service.
  • The resources they own, e.g. the list of actual database schemas they own.

Eligibility view

Users can see to which services they are eligible and not eligible.
If a user is eligible to a service but not subscribed, they can request access.

The eligibility status is determined through a set of Roles mapped to Groups.
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.

Applications and Resources View

By clicking on a service, e.g. "Cloud Infrastructure", a user will see the applications under that service, like "Openstack" in the screenshot above.

On the same page, users can see the resources managed by the service applications they own, grouped by resource type.

Lifecycle operations, such as archiving or deleting the resource or assigning it to another owner (or Resource Group, when support for Resource Groups will be introduced) 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

Applications can be integrated with the Authorization Service in two ways.

For each application, it is possible to define:

  • Subscribed role: determines if a user is subscribed to the application, i.e. if they are allowed to access the application. If not specifed, every user eligible to the containing service is considered to be subscribed by default.
  • Self-subscription group: allows eligible users to subscribe to the application (optionally with the approval, configurable from the groups portal). If not specified, it will be necessary to ensure that users can access the application in some other way (automatic subscription, dynamic groups mapped to the subscribed role etc).
  • Denied role: determines if a user is explicitly denied access to the application. The "denied" logic takes precedence over all other roles. If not specifed, the service enforces no deny mechanism.
  • Admin role: allows application/resource managers to visualize and manage all resources belonging to the service for any user, as well as the users' subscription status.
  • Grace period: allows specifiying a period (in days) during which users keep access to the application after they are unsubscribed from the application (either because they volountarily unsubscribed or because their access rights changed).

Community Edition

This is a lighter integration model, suitable for applications 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 application.

The Authorization Service maintains the users' subscription status, that integrated applications can retrieve 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

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.