Clarity SaaS Authentication in the Google Cloud Platform
ClaritySaaS Authentication in the Google Cloud Platform
Federated SSO integration creates a trusted relationship between
ClaritySaaS and your organization's identity management solution. This relationship delivers the following benefits:
- Seamless integration between networks and environments: All users can move easily between your organization's intranet andClaritySaaS.
- Simplified password management: No need to manage user passwords separately fromClaritySaaS, because your existing user management system handles password management.
- Broadcom Supported: A dedicated Broadcom support organization is available to provide technical support as needed.
Customers can be assured the Identity management tool will authenticate users for access to
Clarityonly after being authorized by the IdP solution. To provide this functionality,
ClaritySaaS supports federated single sign-on using SAML 2.0. This integration creates a trusted relationship between Broadcom’s SaaS infrastructure and your organization's existing enterprise user management system, simplifying end-user password management.
ClaritySaaS currently supports IdP initiated SAML version 2.0 with HTTP-POST Binding. SP initiated SSO can be enabled. However, the customer needs to understand and accept the following limitations:
- A user's favorite links (for projects or timesheets etc.,) saved in the browser, can be used if the user double clicks the link.
- In this scenario, Broadcom does not generate a SAML assertion from its servers The user is simply redirected to the IdP URL.
The recommended solution is to use IdP initiated SSO with Broadcom’s
Organizations that intend to leverage federated SSO with
ClaritySaaS must implement the client-side (IdP) requirements and tools to support SAML federated SSO, such as; CA Single Sign-On, Active Directory Federation Services (ADFS), or other vendors.
Federated SSO Implementation
Requirements to enable Federated SSO with
In order to enable Federated SSO, the following requirements should be met:
- Customers must implement an Identity Management (IdP) solution for user management.
- The customer’s IdP solution must support SAML 2.0.
- Customers must create IdP artifacts passing the required information toClaritySaaS.
- Federated SSO will be enabled for allClaritySaaS environments.
- AllClarityusernames must be defined in a valid email format.
The following flow defines the activities that need to be done to set up Federated SSO in
Information Needed to Enable Federated SSO in
To enable the federated SSO service in GCP, customers start the process by creating a Broadcom Support ticket requesting Federated SSO to be setup. The Support ticket should include the following information:
ClarityURLs for all environments (e.g., Test, Dev, and Prod).
Your SSO Solution Tenant Admin:
Identify one account. This user will be granted access to Broadcom’s Okta, as an administrator, to manage the Okta user group. The user will be responsible for managing non-federated users in your federally authenticated environment. To learn more about creating an Okta tenant admin, see Creating an OKTA Tenant Admin.
Name of Identity Management Solution
This is the name of the IdP application used by your organization. The IdP application will issue a SAML request to
ClaritySaaS. (e.g. ADFS, Okta, PingFederate, etc.).
Email domains your IdP is restricted to
If the user email address is not in these domains,
Clarityauthentication and access will be denied. (e.g., abccompany.com, xyzcompany.com)
Claritylanding page (Default is Modern UX)
Upon successfully logging into
Clarity, the user lands on the defined Modern UX or
Classic PPMpage. Broadcom recommends users land on a defined Modern UX page.
Do you want to restrict user authentication to Federated SSO only? (Yes/No)
If yes, Service Provider initiated authentication will be set up. If no, users will be able to login using Broadcom Okta credentials in addition to IdP or Service Provider initiated authentication.
SAML IdP Issuer ID
The IdP ID can be unique for each environment. This information is needed for all your
ClaritySaaS environments (e.g. Dev, Test, Prod will have unique values for each environment).
SSO Service URL for your IdP
This is the IdP URL. This information is needed for all your
Clarityenvironments (e.g. Dev, Test, Prod will have unique values for each environment).
This is the certificate used to sign the (SAML) assertions.
This is the URL the end user should see when they log out of
Broadcom SaaS supported type of binding used to send SAML Assertion.
Default - 2 minutes
URL configured for either
Classic PPMbased on the information provided by the customer.
NameID should contain OKTA /
Clarityusername (Email format)
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">[email protected]</saml2:NameID>
Is Assertion Encrypted?
Only signing of assertion is supported
Assertion Consumer Service
This information (Service Provider metadata) will be provided to the customer once we set up the IdP information received from the customer.
Session Timeout on OKTA
Software Used to Setup Federation
While Broadcom SaaS Portal Service uses SAML 2.0 standards to provide federated access, understanding the IdP used on the customer side will help Broadcom to better mitigate issues. There are scenarios where we need specific settings unique to the type of software or version number.
Once Broadcom completes the setup process, the following information will be shared with the customer to proceed with their IdP setup.
- RelayState: Based on the customer supplied information provided, Broadcom will share instructions to setup relaystate. Broadcom will share relaystate information for eachClaritySaaS environment.
- Federation Metadata File: Service Provider metadata information.
Once Broadcom completes the SSO setup and provides the SSO setup information, customers need to complete the following activities:
Activities performed by your SSO Team
The customer's SSO team needs to create a new IdP Artifact for each
Clarityenvironment. This artifact has the following SAML assertion requirements:
- NameID should contain theClarityusername in the form of an email address.
- The SAML Attributes are needed in the Assertion (These attributes will be used to provision and update user information in Broadcom Okta.)
- Encryption: Only the signing of assertion is supported.
- Minimum Signature Algorithm when validating SAML Assertions: SHA-256
- RelayState (or TargetURL): This is needed to route the end-user to theClarityenvironment.
Activities Performed by Your Okta Tenant Admin
After the Broadcom team configures the tenant admin in Okta, an email will be sent to the tenant administrator by Okta. The Okta tenant admin needs to perform the following actions:
- Select the link in the email to register in Okta.
- Setup a new password for Okta.
- Set up multi-factor authentication.
Try to login to your current non-production environment by using the new SSO configuration.
Post Setup Activities
Setting up Federated SSO is a coordinated activity between Broadcom and your SSO team. We recommend the following approach:
- Setup an IdP artifact for each of your non-production environments. This should be tested first to ensure the deep linking is configured correctly between your IdP and Broadcom’s Okta.
- After a successful test, we recommend the following:
- Create an IdP artifact for Production and have it ready for Production Go-Live.
- Schedule a go-live weekend when Broadcom will enable SSO for the Production environment, and your team can enable the IdP artifact for all users.
Broadcom’s Okta User Groups
Broadcom will create user groups in Okta, which map to a provisioned
Clarityenvironment. A single user can be part of multiple user groups, allowing them to access multiple
The Broadcom Okta user groups have the following nomenclature:
Example: Consider a tenant named MyBank provisioned on the
MyBank needs DEV and PROD
Clarityinstances. The provisioning process assigned MyBank the tenant domain "cppm4758". In this example, the provisioning process will create two user groups for MyBank:
These user groups correspond to the two
Clarityenvironments provisioned for MyBank.
Clarityadministrators define users in each
Users defined in the non-production environment will be added to the ClarityPPM.MyBank.cppm4758.dev group and users defined in the production environment will be added to the ClarityPPM.MyBank.cppm4758.prod group.
In order for a user to access
Clarityin SaaS, their information needs to exist in multiple systems. Review the process defined below to learn more about creating users in the appropriate systems:
- User Creation In Your User Identity Management SystemIn a system authenticated by a single user management system, the user needs to be created in your IdP. This system will be used to authenticate a user before allowing the user to access theClarityapplication in SaaS. User creation in this system is done by your SSO team.
- User Creation inClarityYour organization'sClarityadministrator can create and manage users, directly withinClarity. When defining users inClarity, the username must be in the form of an email address. If the user name is not defined as an email address, the user will not match Broadcom’s Okta user definition and access will be denied.
- User creation in Broadcom’s OktaBroadcom uses Okta as the system of record for all users accessing Broadcom products in the GCP SaaS infrastructure. Every user accessingClaritymust be a user in Broadcom’s Okta tenant. In addition, user groups within Okta determine the products and environments 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.Customers using a Federated SSO solution withClaritydo not need to additionally create users in Okta. Broadcom’s Okta “Just in time” (JIT) user creation automatically creates users (in Okta), when a SAML request is received. The JIT functionality will perform the following actions:
- When a SAML request is received by Okta, JIT checks if the user exists in Okta.
- If the user exists, the user is navigated directly to the defined targetClarityenvironment (and page).
- If the user does not exist in Okta, the user is automatically created in Okta, added to the Okta user group, and the user is automatically navigated to the targetClarityenvironment.
- Non-Federated User Creation in OktaThe SaaS User Sync job enables Clarity SaaS customers to synchronizeClarityusers with Broadcom Okta and assign them to the appropriate Okta groups. Administrators should manually schedule this job to run regularly. InClarity15.9.1 and future releases, customers do not need to log in to Okta as tenant admin to add users.The SaaS User Sync job reads all users from Clarity that have not been synced previously and then performs the following actions:
If user status inClarityis "inactive", then the job removes the user from the Okta user group, thus revoking their access to the Clarity PPM instance. The user will be marked as not having been synced in case they are reactivated at a future date.To learn more about the SaaS User sync job, see Clarity Jobs Reference.If you are using older releases ofClarity, or want to create users manually as an Okta tenant admin, follow the steps given below. To learn more about creating an Okta tenant admin, see Creating an OKTA Tenant Admin.
- Check if theClarityuser exists in Okta.
- If the username is not in the form of an email address, the user is skipped.
- If the user exists and is in the appropriate Okta group, then the job will not make any changes.
- If the user exists but is not in the appropriate Okta user group, the job will add the user to the appropriate Okta user group.
- If the user does not exist in Okta, the job will create the user and add them to the appropriate Okta user group.
- FromClarity, create the non-federated user via the “Resources” section under Administration.The username format must be a valid email address.
- Your Okta tenant administrator will log into Broadcom’s Okta administration site (http://avagoext.okta.com).The tenant administrator should be the same user identified in “Information needed to enable Federated SSO inClaritySaaS” and should use the same login credentials established when registering in Okta.
- Navigate to the Admin link on the top right of the page.
- Complete multi-factor authentication
- Navigate to “People” under the Directory menu.
- Click on “Add Person”, to create the non-federated user.
- Populate the user information for non-federated users. Some key information you should remember is shared below:
- Users must have a valid email address and must be the same as the username inClarity.
- Ensure the “Send user activation email now” is checked.
- Save the user information. The new user will receive an email from Okta with instructions to register and set up multi-factor authentication.
- Navigate toGroupsunder the Directory menu and add the user to the respective group.
If a non-federated user already exists in Broadcom’s Okta then your Okta tenant admin cannot add them to the Okta user group to grant them access to your
ClaritySaaS environment. Broadcom’s Okta tenant will see the error message below. In such a situation, you need to open a support ticket with Broadcom requesting the existing non-federated user be added to your Okta user group.
Syncing Users Between
Using the JIT functionality, the system will automatically create users in Broadcom’s Okta based on the SAML request. Remember that users must be defined in
Clarityto leverage JIT.
In Clarity 15.9.1 and higher releases, you can specify a secondary email address for a user in
Clarity. This is intended only for
ClaritySaaS customers who want to create test user accounts in
Clarity. In previous releases of
ClaritySaaS, if customers created a test user with an invalid email address then they did not get any Okta activation information. In
Clarity15.9.1 and higher releases, you can create a test user in
Claritywhere the user name and primary email address are invalid and the secondary email will be a valid email. You can use the same secondary email address for all test accounts.
After you create the new user in
Clarity, you can use the SaaS User Sync job to update the details in OKTA for non-federated users. Federated SSO users can leverage Broadcom’s Okta “Just in time” (JIT) user creation, which automatically creates the user (in Okta) after receiving a SAML request. The user’s primary and secondary email is now configured in OKTA. However, once
Claritycreates a user in OKTA, it will not update any details in OKTA. You need to work with your OKTA Group administrator to update user details in OKTA.
Revoking User Access to
In order to revoke user access from
ClaritySaaS, remember the following points:
- Federated users authenticating toClarityusing your IdP should be managed in your IdP.
- User status inClarityshould be changed to “Inactive”.
- Your Okta tenant admin should remove the user from the Broadcom Okta user group.
- Log into Okta as a tenant administrator and navigate to the Admin link.
- Complete the multi-factor authentication.
- SelectPeopleunder the Directory menu.
- Search for the resource whose access you want to revoke and click their name.
- Navigate to theGroupstab and remove the relevant groups.Ensure you remove access to the Development group if you don't want resources to access the development environments.
ClaritySaaS, once Federated SSO has been set up, end users access
Clarityusing one of the following methods:
IdP Initiated Flow (Accessing
Clarityusing Customer’s IdP)
The IdP initiated flow will be the typical method for all end-users to access
- End users navigate to the organization's IdP solution URL.
- End users authenticate via the organization’s IdP.
- Depending on the IdP system in use, end users will typically see an application tile for eachClarityenvironment along with other application tiles for which they have access.
- If end users are presented with multiple tiles/links, they select whichClarityenvironment they want to access.
- If the IdP is configured to route end users directly toClarity, they will land on the definedClaritylanding page.
SP Initiated Flow (Accessing
End-users can access
Claritydirectly from the
ClarityURL. In this situation, the following will occur:
- End users navigate to theClarityenvironment.
- If the user has a validClaritysession, they will land on the definedClaritypage.
- If the user does not have a validClaritysession, they are routed to the IdP authentication page.
- End users will authenticate using the organization’s IdP.
- Depending on the IdP system in use, end-users will either see an application tile for eachClarityenvironment, along with other application tiles for which they have access.
- If end users are presented with multiple tiles/links, they can select theClarityenvironment they want to access.
- If the IdP is configured to route end users directly toClarity, they will land on the definedClaritylanding page.
Non-Federated user access (Accessing
Clarityusing the new SSO URL)
ClaritySaaS, once Federated SSO access is enabled, all
Clarityenvironments are controlled by SSO. However, there may be a case where a customer wants to grant
Clarityaccess to non-federated users (e.g., users not defined in the IdP), to their
Perform the following steps:
- Your Okta Tenant Admin will create a user account for you. They can follow the steps listed in the Non-Federated User Creation in Okta section.
- After the user is created in Okta, your administrator can set the password or send you an activation link.
- Once you receive the link, you need to activate your account by performing the steps listed in the email.
- After the user is activated, you can logout, navigate to https://avagoext.okta.com/login/default, and set up multifactor authentication.
- Navigate to the generic SSO URL - New Customers
- Enter the proper username, in email address format, and password. If multi-factor authentication is enabled, the user must supply the additional authentication information as required.
- After successful login, end-users will land in the definedClaritylanding page.
The XML Open Gateway (XOG) is a
Clarityweb service interface typically used by partners and system administrators to import/export data or move configuration data from one environment to another. XOG uses XML and web services to perform these functions.
This flow is used when a user or integrated system interacts with
ClaritySaaS using the XOG endpoint. When accessing this XOG endpoint, the user or integrated system must specify a defined
Clarityusername and password.
XOG will not support SSO. The XOG transaction is achieved by specifying the
Clarityusername and password for the user who has the authorization to perform the requested XOG. The user will be authenticated using
Creating an OKTA Tenant Admin
Clarityuser cannot be an Okta tenant admin because a
Clarityuser is added under the non-MFA(Multi-Factor Authentication) group and for Okta tenant admin it needs the MFA group.
As a part of the onboarding process, a customer will provide the email address of a user who would be the tenant administrator. Broadcom will provision a new account in Okta by appending -admin to the username. For example, if a customer provides [email protected], Broadcom will generate a new Okta account as [email protected] The email ID associated with this account will be [email protected] Broadcom will assign administrator privileges to the new user account.
The tenant administrator can perform the following steps after they receive an email from Okta:
- Open the email received from Broadcom.
- Click theActivate SSO Accountlink in the email. The tenant administrator can define their password and configure the password recovery options. After the account is created, they will land on the Broadcom home page.
- After activation, the tenant administrator should navigate to https://avagoext.okta.com/login/default and log in by using the account you just created.
- ClickSetupto configure MFA. The tenant administrator can use the EMAIL option to set up MFA.
- They will receive the code on their registered email.
- The tenant administrator can log into Okta and clickAdmin.
- Review Non-Federated User Creation in Okta to see how tenant administrators can add non-federated users in Okta.
Customers should not add the tenant administrator account with “-admin” suffix to their IDP. If the tenant administrator accesses Broadcom OKTA using SSO, multi-factor authentication will be removed. However, the tenant administrator need's multi-factor authentication to be an Okta administrator. In our example, [email protected] should not be added to the customer's IDP.
- What happens if a user is defined in the IdP system, but not defined inClarity?If the user logs into the IdP and navigates toClarity, but the user does not exist inClarity, they will be presented with theClaritylogin page. In this situation,Clarityreceived a SAML request for a user it could not identify.
- Can I provide non-federated users access only to theClaritynon-production environment?Yes, the tenant administrator can limit the non-federated user access to the non-production environment by only adding this user to the non-production Okta user group.
- If we want to enable Federated SSO access toClaritySaaS, then are we required to configure all of ourClarityenvironments with Federated SSO?Yes, Broadcom requires Federated SSO for allClarityenvironments. You cannot set up Federated SSO for only one environment.