Clarity SaaS Authentication in the Google Cloud Platform
Federated SSO integration creates a trusted relationship between SaaS 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 and SaaS.
- Simplified password management: No need to manage user passwords separately from SaaS, 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 only after being authorized by the IdP solution. To provide this functionality, SaaS 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.
SaaS 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 SaaS.
Organizations that intend to leverage federated SSO with SaaS 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 SaaS
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 to SaaS.
- Federated SSO will be enabled for all SaaS environments.
- All usernames 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 SaaS:
Information Needed to Enable Federated SSO in SaaS
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:
Provide the URLs 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 SaaS. (e.g. ADFS, Okta, PingFederate, etc.).
Email domains your IdP is restricted to
If the user email address is not in these domains, authentication and access will be denied. (e.g., abccompany.com, xyzcompany.com)
landing page (Default is Modern UX)
Upon successfully logging into , the user lands on the defined Modern UX or
Clarity 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 SaaS 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 environments (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 or
Clarity PPMbased on the information provided by the customer.
NameID should contain OKTA / username (Email format)
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 each SaaS 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 environment. This artifact has the following SAML assertion requirements:
- NameID should contain the username 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 the environment.
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 environment. A single user can be part of multiple user groups, allowing them to access multiple SaaS environments.
The Broadcom Okta user groups have the following nomenclature:
Example: Consider a tenant named MyBank provisioned on the GCP infrastructure.
MyBank needs DEV and PROD instances. 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 environments provisioned for MyBank. administrators define users in each environment.
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 in 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 the application in SaaS. User creation in this system is done by your SSO team.
- User Creation inYour organization's administrator can create and manage users, directly within . When defining users in , 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 accessing must 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 with do 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 target environment (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 target environment.
- Non-Federated User Creation in OktaIf you require a non-federated user to access your SaaS instance then that user needs to be created in Broadcom’s Okta tenant by your Okta tenant admin. To learn more about creating an Okta tenant admin, see Creating an OKTA Tenant Admin.Perform the following steps:
- From , 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 in SaaS” 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 in .
- 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 SaaS 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 and Okta
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 to leverage JIT.
Revoking User Access to
In order to revoke user access from SaaS, remember the following points:
- Federated users authenticating to using your IdP should be managed in your IdP.
- User status in should be changed to “Inactive”.
- Your Okta tenant admin should remove the user from the Broadcom Okta user group.
In SaaS, once Federated SSO has been set up, end users access using one of the following methods:
IdP Initiated Flow (Accessing using 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 each environment along with other application tiles for which they have access.
- If end users are presented with multiple tiles/links, they select which environment they want to access.
- If the IdP is configured to route end users directly to , they will land on the defined landing page.
SP Initiated Flow (Accessing using URL)
End-users can access directly from the URL. In this situation, the following will occur:
- End users navigate to the environment.
- If the user has a valid session, they will land on the defined page.
- If the user does not have a valid session, 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 each environment, along with other application tiles for which they have access.
- If end users are presented with multiple tiles/links, they can select the environment they want to access.
- If the IdP is configured to route end users directly to , they will land on the defined landing page.
Non-Federated user access (Accessing using the new SSO URL)
In SaaS, once Federated SSO access is enabled, all environments are controlled by SSO. However, there may be a case where a customer wants to grant access to non-federated users (e.g., users not defined in the IdP), to their environment.
After the non-federated user is defined in Broadcom’s Okta, the non-federated user can log in to using the following steps listed below:
- Navigate to the generic SSO URL.The newly provision URLs in GCP are:Current customers transitioning to GCP can use:
- 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 defined landing page.
Accessing via XOG
The XML Open Gateway (XOG) is a web 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 SaaS using the XOG endpoint. When accessing this XOG endpoint, the user or integrated system must specify a defined username and password.
XOG will not support SSO. The XOG transaction is achieved by specifying the username and password for the user who has the authorization to perform the requested XOG. The user will be authenticated using authentication.
Creating an OKTA Tenant Admin
A user cannot be an Okta tenant admin because a user 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 firstname.lastname@example.org, Broadcom will generate a new Okta account as email@example.com. The email ID associated with this account will be firstname.lastname@example.org. 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/ 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@example.com should not be added to the customer's IDP.
- What happens if a user is defined in the IdP system, but not defined in ?If the user logs into the IdP and navigates to , but the user does not exist in , they will be presented with the login page. In this situation, received a SAML request for a user it could not identify.
- Can I provide non-federated users access only to the non-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 to SaaS, then are we required to configure all of our environments with Federated SSO?Yes, Broadcom requires Federated SSO for all environments. You cannot set up Federated SSO for only one environment.