Federation and Single Sign-on for the ClientNet Portal

Symantec uses Okta for both Single Sign-on (SSO) and federation of user accounts. Okta is an identity provider (IdP) that offers user authentication as a service. Email Security.cloud customers can now choose to register with Okta using any valid email address or to federate their corporate IdP with Okta.
Before the February 2021 release,
users signed in to ClientNet using one of two methods:
Username and Password
This method uses ClientNet to create and store credentials for users. Administrators create and delete each account, and also assign roles to users. Authentication information is stored and managed by ClientNet, and users must manage their credentials in addition to all of their separate credentials for other Symantec products and services.
To improve security (by allowing customers to control their own user authentication data) and to improve the user experience (by providing SSO), this method is being phased out. The phase-out is gradual, to allow customers time to plan and configure either Okta SSO or federation with an Okta-supported IdP. After migration is complete, customers can still use these credentials to call APIs and use standalone tools (this is called a
account) but cannot use them to sign in to ClientNet.
Symantec Account
This method originally used Norton Secure Login to provide a single sign-on experience for customers who use multiple Symantec products and services. With the new release, this method now uses Okta technology to enable SSO functionality.
Beginning with the February 2021 release,
when an existing user signs in to the ClientNet portal for the first time, a migration wizard is automatically displayed. The wizard helps users with the one-time process of linking their current ClientNet accounts to SSO or federated accounts. Because user responses to the wizard’s prompts will differ depending on whether your organization plans to use Symantec Accounts for SSO or to federate using a non-Okta IdP, it’s a good idea to determine your strategy as soon as possible after SSO/federation becomes available. Your organization must decide whether to implement:
Username and Password (Temporary)
Allows traditional ClientNet access with no SSO or federation. User authentication data is stored and managed by ClientNet. Users can click the
Decide Later
button in the migration wizard to postpone migration until your organization is prepared to implement Symantec Accounts or federation.
Symantec Account (SSO based on Okta)
Allows users to sign in using a single username/password combination that is shared among all Symantec products and services. Username is always an email address, and every unique user must have an account. Users’ authentication data is stored and managed by Okta.
SSO/federation using a different Okta-supported IdP
Allows your users to sign in using a single username/password shared across Symantec products. Users’ authentication data is stored and managed by your IdP.
Configuring SSO with Okta
Because Okta is already the underlying technology used for signing in to Symantec Accounts, you do not need to configure Okta itself (as you do for a partner IdP). After all users have used the wizard to migrate to Symantec Accounts and new users have been added and had their roles set up, your configuration and migration tasks are complete. After Symantec Account SSO is set up, it can be used for other Symantec products. If a user already has an existing login for a different Symantec product, then the user can continue to use that login rather than setting up a new account for Email Security.cloud.
Configuring federation with a partner IdP
You can configure federation with your own IdP, provided Okta supports it. See the Okta website at www.okta.com to confirm that your partner IdP is supported.
Federation with a partner IdP must be initiated by opening a support ticket. You can do this from within ClientNet by clicking the
tab on the right side of every portal page. You can also access Support directly by navigating to https://support.broadcom.com/security and clicking
Case Management
. You must be connected to the Site ID that includes Email Security.cloud as a product.
When you open a support ticket to request federation, you must provide:
  • The email domain(s) for your users
  • An XML fragment containing metadata about your IdP that the IdP provides
  • Attribute mappings for the standard attributes within Broadcom’s IdP:
    • The email domain(s) for your users
    • Email address
    • FirstName
    • LastName
    • Groups: a list of security/access groups to which a specific user should belong
    • PartnerUserId: the unique user ID in the federated IdP
Migrating existing ClientNet users to SSO/federation
When an existing user signs on to the ClientNet portal for the first time after SSO/federation became available, a migration wizard is automatically displayed. The wizard helps users with the one-time process of linking their current ClientNet accounts to SSO/federated accounts. The wizard detects information about the user’s current authentication status, and walks the user through addressing these situations:
  • Duplicate:
    If the user has a shared account, click this button to create a duplicate account linked to the user’s email address. This allows the other users that share the account to follow the same migration path so that all of the newly created accounts have the same access level.
  • Link Accounts:
    If the user has a Symantec (federated) account, click this button to link this ClientNet account to the user’s Symantec Account.
  • Link to Other:
    If the user does not have a Symantec (federated) account linked to this email address but does have an account linked to a different email address, click this button to link the user to that other Symantec (federated) account.
  • Create New:
     If the user does not have a Symantec (federated) account, click this button to create a new account using the existing email address, or enter a different email address for the user.
Because the wizard is displayed only for existing users, no further action is required by administrators to configure a current user’s portal account. Existing users do not need to have roles and privileges assigned—their previous roles are preserved.
If the wizard does not display because the user has already migrated to Okta, you can force the wizard to display by clicking
Dissociate Login
on the
Creating federated accounts for new ClientNet users
Users who are new to ClientNet--or are newly federated--must have accounts created for them by an administrator so that their access roles can be assigned.
Creating a new user
  1. In the portal, navigate to
    Dashboard > Administration > User Management
    and click
    Create New User.
  2. On the
    User Details
    tab, ensure that
    Federated User
    is selected.
    Federated User
    does not appear until
    Federated login only
    is enforced at the portal level. If you are not yet enforcing federated logins, then the only option is to select
    Portal user
    and then ignore the account activation email.
    Service user
    should be selected only when you intend to use the credentials you are adding to call APIs and use standalone ClientNet-related tools.  Service user credentials cannot be used to access the ClientNet portal.
  3. Enter the first name, last name, email address (the federated login email address), language, and time zone for the user.
  4. Specify whether the user is enabled or disabled. Disabling a user allows you to temporarily prevent the user from accessing the portal without having to permanently delete the user’s account.
  5. Specify whether the user is permitted to manage other users. (Choose
    if the user you are adding is an administrator.)
  6. Select
    Link to existing Symantec Account
    at the bottom of the page.
  7. Click
    Save and Exit.
Now that you have created the portal account for a new ClientNet user, the next step is to assign roles for that user.
Assigning roles to a new or newly federated user
  1. In the portal, navigate to
    Dashboard > Administration > User Management.
  2. Click the
    User roles
  3. Click
    Use standard role.
  4. Select the role type to apply for this user.
  5. Click
    Add role.
The role is now listed in the
User roles
Enforcing federated sign-ins at the portal level
Once you have configured SSO/federation with Okta or a partner IdP and migrated all of your users, the final step is to enforce federation at the portal level.
Enforcing federation automatically
all other sign-in methods for users of that portal. Do not perform the steps below until you have configured federation with your IdP and all of your users have used the migration wizard to link their pre-federation accounts to federated ones.
Enabling or disabling federation
  1. In the ClientNet portal, navigate to
    Dashboard > Administration > Access Control.
  2. Use the slider to turn federation on or off for all ClientNet portal users.
See also