Onboarding Original Subscriptions to VMware Cloud Services | VMware Aria Operations for Applications Documentation

Learn about how we migrate the authorization and authentication from Operations for Applications to VMware Cloud services.

Starting July 3, 2023, VMware Aria Operations for Applications is a service on the VMware Cloud services platform. We are in the process of incrementally onboarding all original subscriptions to VMware Cloud services.

What Should I Do Before the Onboarding?

Currently, all original Operations for Applications subscriptions are integrated with VMware Cloud services for billing and subscription management. Therefore, you must already have a VMware Cloud organization with at least one user with the VMware Cloud Organization Owner role.

Before the onboarding:

Get familiar with the VMware Cloud service platform. See Getting Started with Operations for Applications on VMware Cloud Services.
Verify that your VMware Cloud Organization Owner user can log in to the VMware Cloud Services Console.
- If you are the VMware Cloud Organization Owner user and cannot log in, try using the Forgot Password option.
- If your VMware Cloud Organization Owner user is unreachable or you don’t know the name of your VMware Cloud Organization Owner user, contact our Technical Support team for assistance.
If you have a SAML SSO integration, as a VMware Cloud Organization Owner user, you must federate your currently integrated enterprise domain with your VMware Cloud organization. For details, see the Setting Up Enterprise Federation with VMware Cloud Services Guide in the VMware Cloud services documentation.

Warning: If you do not federate your currently integrated enterprise domain, after onboarding to VMware Cloud services all users will lose access to the service.

What’s the Onboarding Process?

The onboarding is done by our team. If you are currently using a SAML SSO integration, you must only federate your enterprise domain before the process starts. The following flowchart shows the overall process.

Onboarding flowchart. Each stage of the process is described below.

Here’s the process:

You receive a notification in your service UI with the date scheduled for your service onboarding to VMware Cloud services.
If you are using a SAML SSO integration, your VMware Cloud Organization Owner user federates your currently integrated enterprise domain with your VMware Cloud organization. That must happen before the scheduled onboarding date.
On the scheduled date, we onboard your service instance to VMware Cloud services, that is, we migrate your users, roles, and groups to your VMware Cloud organization. During the process, there’s a banner notification in your service UI.

Important: During the onboarding, you should not to do any changes related to users, roles, groups, and permissions. Such changes might be lost.
When the onboarding completes, you can see a banner notification in your service UI and, shortly after that, all active users are logged out.
Each user receives an email with an invitation link to sign up to VMware Cloud services.

The invitation links are valid for seven days.
Each user redeems the invitation link and signs up to the VMware Cloud Services Console.
- The users of a non-federated domain must create a password for their VMware Cloud services account.
- The users of a federated domain must log in with their existing corporate passwords.

Tip: From now on, all users log in to the service instance from the VMware Cloud Services Console.

How Are the Users Migrated to VMware Cloud Services?

During the process of onboarding your Operations for Applications service to VMware Cloud services, we add all your current users to your VMware Cloud organization running the service.

An image displaying how users are migrated when your Operations for Applications service is onboarded to VMware Cloud services. The information from the image is explained in the bullet list below.

If a user is a Super Admin in Operations for Applications, we assign that user with the Super Admin Operations for Applications service role in VMware Cloud services.
If a user is assigned with individual permissions in Operations for Applications, we assign that user with the corresponding Operations for Applications service roles in VMware Cloud services. For example, if a user has the Alerts permission in Operations for Applications, we assign that user with the Alerts Operations for Applications service role in VMware Cloud services. There are the following exceptions:
- The Accounts permission is replaced by the VMware Cloud Organization Administrator role plus the Admin Operations for Applications service role.
- The API Tokens permission is not replaced by any role, because this privilege is not needed in VMware Cloud services. Each VMware Cloud services user can manage their own VMware Cloud services API tokens.
- The SAML IdP Admin permission is not replaced by any role, because this privilege is not needed in VMware Cloud services. The VMware Cloud Organization Owner initiates enterprise federation for your corporate domain and assigns an Enterprise Administrator.
For details, see the permissions differences.
If a user does not have any permissions and roles in Operations for Applications, we assign that user with the Viewer Operations for Applications service role in VMware Cloud services.
If a user is assigned with roles in Operations for Applications, we assign that user with the corresponding custom roles in VMware Cloud services. See How Are the Roles Migrated to VMware Cloud Services?.
If a user belongs to a group in Operations for Applications, we add that user to the corresponding group in VMware Cloud services. See How Are the Groups Migrated to VMware Cloud Services?.

Tip: From now on, users with the VMware Cloud Organization Owner and Organization Administrator roles can manage the Operations for Applications users in the VMware Cloud Services Console.

How Are the Groups Migrated to VMware Cloud Services?

Originally, your Operation for Applications service includes the Everyone and Service Accounts system groups as well as any other custom groups that you have created.

How Are the Custom Groups Migrated?

During the process of onboarding your Operations for Applications service to VMware Cloud services, for each group that you have created in Operations for Applications, we create a corresponding group in your VMware Cloud organization running the service.

The corresponding VMware Cloud groups are with the same names and descriptions as the original Operations for Applications custom groups.
All users from a custom group in Operations for Applications are added to the corresponding VMware Cloud group.
The service accounts from the custom groups in Operations for Applications are not added to any VMware Cloud group.

Important: Currently, VMware Cloud services supports grouping only for user accounts.
If a custom group in Operations for Applications is assigned with roles, the corresponding VMware Cloud group is assigned with the corresponding VMware Cloud custom roles. See How Are the Roles Migrated to VMware Cloud Services?.

Tip: From now on, users with the VMware Cloud Organization Owner and Organization Administrator roles can manage the user groups in the VMware Cloud Services Console.

How Is the Everyone System Group Migrated?

During the process of onboarding your Operations for Applications service to VMware Cloud services, for the Everyone system group in Operations for Applications, we create the corresponding All Operations for Applications Users group in your VMware Cloud organization running the service as follows:

All current users are added to the All Operations for Applications Users VMware Cloud group.

Important: New users will no longer be added automatically to this group.
The All Operations for Applications Users VMware Cloud group is assigned with the All Operations for Applications Users VMware Cloud custom role, which corresponds to the Everyone role in Operations for Applications. See How Are the Roles Migrated to VMware Cloud Services?.
If the Everyone system group in Operations for Applications is assigned with custom roles, the All Operations for Applications Users VMware Cloud group is assigned with the corresponding VMware Cloud custom roles. See How Are the Roles Migrated to VMware Cloud Services?.
In Operations for Applications, we continue to maintain the Everyone system group only as a local internal group that is automatically populated with all new users. This group has no roles and permissions.

Tip: From now on, it is up to you to add new users to the All Operations for Applications Users VMware Cloud group. The Everyone internal system group can be used only when managing access to dashboards and alerts, metrics security policy rules, and ingestion policies.

What Happens with the Service Accounts System Group?

During the process of onboarding your Operations for Applications service to VMware Cloud services, we do not migrate the Service Accounts system group.

Important: Currently, VMware Cloud services supports grouping only for user accounts.

The permissions from the roles assigned to the Service Accounts system group in Operations for Applications are now directly assigned to the service accounts. See What Happens with the Service Accounts?.
In Operations for Applications, we continue to maintain the Service Accounts system group only as a local internal group that is automatically populated with all service accounts and server to server OAuth apps that have access to the service instance. This group has no roles and permissions.

Tip: From now on, the Service Accounts internal system group can be used only when managing access to dashboards and alerts, metrics security policy rules, and ingestion policies.

How Are the Roles Migrated to VMware Cloud Services?

During the process of onboarding your Operations for Applications service to VMware Cloud services, for each role in Operations for Applications, we create a corresponding custom role in your VMware Cloud organization running the service as follows:

For each role that you have created in Operations for Applications, we create a corresponding VMware Cloud custom role with the same name and description.
For the Everyone role that is assigned to the Everyone system group in Operations for Applications, we create the All Operations for Applications Users VMware Cloud custom role. See How Is the Everyone System Group Migrated?.
For the Service Accounts role that is assigned to the Service Accounts system group in Operations for Applications, we do not create any VMware Cloud custom role, because this group is not migrated. See What Happens with Service Accounts System Group?.
The corresponding VMware Cloud custom roles are assigned with the same permissions as the original roles in Operations for Applications. There are the following exceptions:
- The Accounts permission in Operations for Applications is replaced by the Admin Operations for Applications permission in VMware Cloud services. In addition, the users with that permission are assigned with the VMware Cloud Organization Administrator role.
- The API Tokens permission in Operations for Applications is not replaced by any permission in VMware Cloud services. This permission does not exist in VMware Cloud services, because each user can manage their own VMware Cloud services API tokens.
- The SAML IdP Admin permission in Operations for Applications is not replaced with by permission in VMware Cloud services. This permission does not exist in VMware Cloud services, because the VMware Cloud Organization Owner initiates enterprise federation for your corporate domain and assigns an Enterprise Administrator.
For details, see the permissions differences.

Tip: From now on, users with the VMware Cloud Organization Owner and Organization Administrator roles can manage the custom roles in the VMware Cloud Services Console.

What Happens with the Service Accounts?

During the process of onboarding your Operations for Applications service to VMware Cloud services, the service accounts are not migrated to VMware Cloud services, because VMware Cloud services supports server to server OAuth apps, which are equivalent to the services accounts in Operations for Applications.

Warning: The usage of service accounts in Operations for Applications on VMware Cloud services is restricted to support only a limited list of integrations that still authenticate with Operations for Applications API tokens. We are in the process of updating all of our integrations to authenticate with VMware Cloud services access tokens. Service accounts and Operations for Applications API tokens will be deprecated in the future.

For backward compatibility, all of your service accounts are preserved in Operations for Applications as follows:

The service accounts no longer belong to groups, because the groups management is migrated to VMware Cloud services.
The service accounts no longer have roles, because the roles management is migrated to VMware Cloud services.
The service accounts are assigned with their existing permissions, including the permissions that they have inherited from roles and group roles. Exceptions are the API Tokens and SAML IdP Admin permissions, which no longer exist.

Note: The Accounts permission in Operations for Applications corresponds to the Admin Operations for Applications permission in VMware Cloud services.
All service accounts still belong to the Service Accounts system group, which is now only an internal Operations for Applications group that is automatically populated with all service accounts and server to server OAuth apps that have access to the service instance. This group has no roles and permissions.

You should incrementally replace your service accounts in Operations for Applications with server to server OAuth apps in VMware Cloud services.

Tip: From now on, users with the VMware Cloud Organization Owner, Organization Administrator, or Organization Member with Developer roles can manage server to server apps in the VMware Cloud Services Console. Users with the Admin service role can manage the service accounts in Operations for Applications. The Service Accounts internal system group can be used only when managing access to dashboards and alerts, metrics security policy rules, and ingestion policies.

How to Replace a Service Account with a Server to Server App?

Service accounts authenticate with Operations for Applications API tokens, while server to server OAuth apps authenticate with the more secure VMware Cloud services access tokens. Service accounts are supported for a limited list of integrations but will be deprecated in the future.

After onboarding to VMware Cloud services, you should incrementally replace your service accounts in Operations for Applications with server to server OAuth apps in VMware Cloud services.

The flowchart on the right shows the overall process for creating a server to server OAuth app and replacing a service account with it.

Flowchart showing how to replace a service account with a server to server app. The process is described in the list below

Log in to the VMware Cloud Services Console as an Organization Owner, Organization Administrator, or Organization Member with the Developer role assigned.

Create a server to server OAuth app. See How to use OAuth 2.0 for server to server apps in the VMware Cloud services documentation.

For the server to server app name and description, you can enter the name and the description of the service account that you want to replace.
For the time to live (TTL) of the access tokens that will be issued to that server to server app, you can configure a value from 1 to 300 minutes. This value defines the period in which the access token should be renewed.

For the scopes of the server to server app, you must configure the roles that correspond to the permissions of the service account that you want to replace:

Scope	Description
Organization Role	Organization Member is sufficient in most of the cases.
Custom Roles	Optional. Use only if you previously created a custom role with the necessary Operations for Applications permissions.
Service Roles	Required for service access. Assign the Operations for Applications service roles that correspond to the permissions of the service account that you want to replace. If you already assigned a custom role, you must assign at least the Viewer Operations for Applications service role.

Make sure that you save the app credentials (ID and secret) of your newly created server to server app to a secure location.

Important: This is the only time you can see and save the app secret. If you miss to copy it or lose it, you must regenerate the app secret.
Add the server to server app to your VMware Cloud organization.
Reconfigure your scripts, API calls, or proxies to exchange the app credentials for an access token, instead of using the API tokens associated with the service account.

Important: Depending on the TTL that you configured for the app access tokens, make sure that your script renews the access token periodically before it expires. The Wavefront proxy does this automatically.
Log in to your service instance as a user with the Admin service role and deactivate or delete the service account that you replaced.

What Happens with the Operations for Applications API Tokens?

During the process of onboarding your Operations for Applications service to VMware Cloud services, the Operations for Applications API tokens are not migrated to VMware Cloud services, because Operations for Applications on VMware Cloud services supports authentication with:

VMware Cloud services API tokens associated with user accounts.
Server to server OAuth apps credentials, that is, app ID and app secret. The server to server OAuth app must belong to the organization that is running the Operations for Applications service.

You must exchange a VMware Cloud services API token or the credentials (ID and secret) of server to server OAuth app for a VMware Cloud services access token.

For backward compatibility, all of your API tokens are preserved in Operations for Applications as follows:

The Operations for Applications API tokens associated with user accounts are no longer editable. The users can still use, view, and revoke their Operations for Applications API tokens until they expire, but they cannot generate new ones.
The Operations for Applications API tokens associated with service accounts are editable, because we still support them for a limited list of integrations.

You should incrementally replace your Operations for Applications API tokens with VMware Cloud services API tokens and server to server OAuth apps.

Tip: From now on, all users must generate VMware Cloud services API tokens for their accounts and exchange them for access tokens. Users with the VMware Cloud Organization Owner, Organization Administrator, or Organization Member with Developer roles can create server to server OAuth apps and exchange the app credentials for access tokens.

How to View and Manage the Operations for Applications API Tokens?

Users with the Admin Operations for Applications service role can manage the Operations for Applications API tokens in the service instance.

Each user can view and revoke their own Operations for Applications API tokens:

Log in to your service instance.
From the gear icon on the toolbar, select your username.
Click the API Access tab and view all your Operations for Applications API tokens.
To revoke a token, click the Revoke button for the token.

If you run a script that uses a revoked token, the script returns an authorization error.

How to Replace an Operations for Applications API Token with a VMware Cloud Services Access Token?

It’s recommended to use Operations for Applications API tokens only for a limited list of integrations. We will update these integrations to authenticate with VMware Cloud services access tokens in a future release.

You should incrementally replace your Operations for Applications API tokens with the more secure VMware Cloud services access tokens.

To replace an Operations for Applications API token associated with a service account, you must replace the service account with a server to server OAuth app. See How to Replace a Service Account with a Server to Server App?.

The flowchart on the right shows the overall process for replacing an Operations for Applications API token with a VMware Cloud services API token.

Flowchart showing how to replace an Operations for Applications API token with a VMware Cloud services API token. The process is described in the list below

To replace an Operations for Applications API token associated with your user account:

Generate an API token. See How do I generate API tokens in the VMware Cloud services documentation.

For the name of the VMware Cloud services API token, you can enter the name of the Operations for Applications API token that you want to replace.
For the time to live (TTL) of the VMware Cloud services API token, you can configure a value from several minutes to several months, or never expire. This value defines the period in which the API token should be renewed.

The TTL of the access tokens that will be issued to that API token is 30 minutes and is not configurable.

For the scopes of the API token, you must configure the minimum portion of your roles:

Note: Till now, the Operations for Applications API tokens inherited all your permissions and roles. Now, you can set the VMware Cloud services API token with a subset of the roles that you own.

Scope	Description
Organization Role	Organization Member is sufficient in most of the cases.
Custom Roles	Optional. Use only if you have assigned a custom role.
Service Roles	Required for service access. If you already assigned a custom role, you must assign at least the Viewer Operations for Applications service role.

Reconfigure your scripts, API calls, or proxies to exchange the newly generated VMware Cloud services API token for an access token, instead of using the Operations for Applications API token.

Important: The TTL of the access tokens associated with user accounts is 30 minutes. Make sure that your script renews the access token periodically before it expires. The Wavefront proxy does this automatically.
Revoke the Operations for Applications API token that you replaced.

What Happens with the Wavefront Proxies?

During the process of onboarding your Operations for Applications service to VMware Cloud services, all of the existing Wavefront proxies are preserved with their existing Operations for Applications API tokens.

You should incrementally replace the tokens of your proxies to authenticate with the more secure VMware Cloud services access tokens.

Tip: From now on, the users with the Proxies service role can create and manage the proxies in your Operations for Applications service. New proxies must authenticate with VMware Cloud services access tokens unless used for the limited list of integrations that still authenticate with Operations for Applications API tokens.

How to Replace the Operations for Application API Token of a Wavefront Proxy?

Important: Make sure the version of your Wavefront proxy is 13.0 or later.

Log in to the VMware Cloud Services Console.
Obtain OAuth app credentials (recommended) or a VMware Cloud services API token:
- Create a server to server app with the Proxies service role, save its OAuth credentials (app ID and app secret), and add it to your VMware Cloud organization. See How to use OAuth 2.0 for server to server apps in the VMware Cloud services documentation.
  
  Also, obtain the long ID of the VMware Cloud organization. See View the Organization ID in the VMware Cloud services documentation.
- Generate a VMware Cloud services API token with the Proxies service role. See How do I generate API tokens in the VMware Cloud services documentation.
Go to the proxy configurations location and edit the wavefront.conf file with the OAuth app credentials or your VMware Cloud services API token:
- Replace the token parameter with the cspAppId, cspAppSecret, and cspOrgId parameters:
```
  cspAppId=<OAuth_app_id>
  cspAppSecret=<OAuth_app_secret>
  cspOrgId=<Org_long_ID>
```
- Replace the token parameter with the cspAPIToken parameter:
```
  cspAPIToken=<VMware_Cloud_services_API_token>
```
Revoke the Operations for Applications API token that you replaced.

What Happens with the Integrations?

During the process of onboarding your Operations for Applications service to VMware Cloud services, all of the existing integrations are preserved and continue to operate using proxy authentication with Operations for Applications API tokens.

You should incrementally replace the proxy tokens of your integrations that are updated to use proxy authentication with the more secure VMware Cloud services access token.

Tip: From now on, the users with the Proxies and Integrations service roles can set up integrations in your Operations for Applications service. New integrations must use proxy authentication with VMware Cloud services access tokens except for the limited list of integrations that still authenticate with Operations for Applications API tokens.