Welcome to the Clarity PPM SaaS Transition Blog series. This blog series provides customers updates regarding the Clarity PPM SaaS transition to the Google Cloud Platform™ (GCP). This is the fourth post of the series. In the first post, Broadcom provided an overview of the transition process and discussed the benefits of transitioning to GCP. In the second post, Broadcom focused on pre-transition activities customers and Broadcom will perform before any of the Clarity PPM environments are transitioned to GCP. In the third post, Broadcom focused on the transition activities customers and Broadcom will perform during the transition to the GCP platform.
In this blog post, the focus will be on authentication methods available for Clarity PPM SaaS in Broadcom's Google CloudPlatform (GCP) based SaaS infrastructure.
Broadcom's SaaS offering will provide you with a single login experience for its SaaS-based products. You will be able to access Broadcom products that you subscribed to, in a single location.
You will be able to login to Broadcom's SaaS platform by using one of the following methods:
By default, all customers will be set up to use Broadcom's Okta-based solution. Your email address will be configured as the username. You will need to raise a request with Broadcom support if you want to enable federated SSO integration to use your IdP as the authentication method.
Federated SSO integration allows you to create a trusted relationship with Clarity PPM SaaS and your identity management solution. This relationship delivers the following benefits:
Broadcom leverages the following components to support the different authentication methods in the GCP SaaS infrastructure.
Broadcom uses Okta as the system of record for users that access Broadcom products in GCP based SaaS infrastructure. Every user that accesses Clarity PPM must be a user in the Broadcom's Okta tenant. In addition, user groups within Okta determine the products and instances of those products a user can access. A user may be a member of one or more user groups depending on the products and instances they can access.
Clarity PPM administrators in your organization can create and manage users, within Clarity PPM. When defining users in Clarity PPM, the username has to be set to the user's email address.
After defining a user in Clarity PPM, administrators can use the Sync SaaS Users job to synchronize the users in Okta and assign them to the appropriate Okta groups. Administrators should manually schedule this job to run regularly.
The Sync SaaS Users job will only be available in Clarity PPM 15.8 and higher versions of Clarity PPM SaaS.
The Sync SaaS Users job uses the following parameters:
The Sync SaaS Users job first reads the parameters from the "System Options" page. Broadcom will specify the default parameters when they provide you with the GCP environment. Administrators can overwrite these parameters when they invoke the job and provide different values for the parameters.
The "Sync SaaS Users" job will perform the following actions:
The Sync SaaS Users job will not deactivate or lock a user in Okta even if they are deactivated or locked in Clarity PPM. This is because the user could have access to other Broadcom products. The status of the user in Clarity PPM should not control their access to other products.
The Broadcom team will create user groups in Okta to map to a provisioned Clarity PPM environment. A single user could be part of multiple user groups, thus allowing them to access multiple Clarity PPM environments in SaaS.
The User groups have the following nomenclature:
Consider an example where a tenant called MyBank is provisioned to use Clarity in GCP.
MyBank needs two types of Clarity PPM instances, namely dev and prod. The provisioning process assigned MyBank the tenant domain "cppm4758". In this scenario, the provisioning process would create two user groups for MyBank:
These user groups correspond to the two instances of Clarity that will be running for MyBank. Clarity PPM administrators will need to define users in each instance of Clarity PPM. The administrator would then use the Sync SaaS Users on each instance to sync users with the relevant groups in Okta.
The users defined in the dev environment will be added to the ClarityPPM.MyBank.cppm4758.dev group and the users defined in the production environment would be added to the ClarityPPM.MyBank.cppm4758.prod group.
The table below compares how users are managed in Broadcom Okta (in GCP) versus CA On-Demand Portal (in the previous data center). The fundamental difference is that in the previous data center environment, tenant administrators managed users via the CA On-Demand Portal.
In the new GCP data center environment, Clarity PPM administrators will manage users directly within Clarity PPM by using either the native user management capabilities in Clarity PPM or by using XOG.
CA On-Demand Portal
The Broadcom team provisions a tenant and creates the requested instances. Customers may have separate instances of Clarity PPM for production, development, and testing associated with one tenant.
The Broadcom team provisions a tenant and creates the instances. Broadcom also creates groups in Okta that will be mapped to your various Clarity PPM instances.
Broadcom creates a single-tenant administrator and assigns it to the relevant resource in your organization.
Broadcom creates a Clarity PPM administrator for all the Clarity PPM instances.
The tenant administrator uses the On-Demand Portal to create users and assigns them to various application services.
The Clarity PPM administrator creates users in Clarity by using the Resources page or by using XOG.
The tenant administrator runs a portal job to synchronize users created in the On-Demand Portal with the relevant Clarity instance.
The Clarity PPM administrator runs the SaaSUserSync job to synchronize users from Clarity to Okta.
The tenant administrator can update user fields in the CA On-Demand Portal.
The Clarity PPM administrator can update user information by using the Resources page or XOG.
The tenant administrator can remove a user from application services or deactivate the user by using the On-Demand Portal.
The Clarity PPM administrator can deactivate or lock the user account by using the Resource page. They can then run the SaaSUserSync job to synchronize users from Clarity to Okta.
It's important to remember that tenant administrator used the On-Demand User Management utility (ODUM) in the previous data center environment to add or modify users and grant or withdraw access to any of the CA On-Demand application services. This functionality will not be available in GCP and Clarity PPM administrators can use the XOG utility to make bulk changes to users.
To enable the federated SSO service in GCP, you need to create a Broadcom support ticket with the following information :
This concludes Part 1 of the GCP Authentication Methods post. Thank you for being a part of the Clarity PPM community. Please write to firstname.lastname@example.org in case you have any specific questions for us. The next blog will be published on March 23rd will include authentication flow diagrams and some commonly asked questions on authentication mechanisms in GCP.
#ca_clarity_ppm #gcp #clarityppmsaas