FAQ: Email.cloud Federation and Symantec account by Okta SSO

Products

• Email Security.cloud

Issue/Introduction

Email.cloud can now use SSO via Federation of user accounts via the client’s own IdP or Symantec Accounts (via Okta). Okta is an identity provider (IdP) that offers user authentication as a service. 

With the release of SSO 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.

 

Resolution

If you've come across an issue or have a query that isn't mentioned below, please open a support case, and we'll be sure to address and include it.

Index:

1. Configuring SSO with Okta (using Symantec Accounts)
2. Differences between Symantec account(Okta) and Federated users
3. Configuring federation with a partner IdP
4. Migrating existing ClientNet users to SSO/federation
5. Creating federated accounts for new ClientNet users
6. Enforcing federated sign-ins at the portal level
7. What IdPs are supported?
8. Enabling or disabling federation
9. I’m already using federated SSO (via Okta) with other Symantec products. Do I need to re-register my IdP?
10. I was using SSO via Norton Secure Login (NSL), can I continue to use it?
11. Disconnect portal link or account link?
12. Where to get the xml metadata file?
13. As a user, can I use Symantec Account via Okta and Federation at the same time?
14. The account exists in Email.cloud as a “portal user”, if it is deleted from Email.cloud will this delete them from the Broadcom Okta portal?
15. Where do I find the attributes for the mapping?
16. What happens if the Audience and ACS url provided to the customer don’t work?
17. I'm using Email quarantine, can I use my federated login?
18. Are there okta apps for Quarantine or Clientnet? 
19. I've linked my clientnet user to Symantec account in the past, but never used it to login. How do I check the email address I used to link my Symantec account to ClientNet?
20. As an admin how do I check the email address my user used to link their Symantec account?
21. Can’t login with old type usernames or Symantec account?
22. Can’t login, forgot my password
23. Can’t login with federated user.
24. After enforcing Federated login only none of users can login
25. Does Okta SSO solution used by Email.cloud offer SCIM integration?

Configuring SSO with Okta (using Symantec Accounts)

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). Once 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. Once Symantec Account SSO is set up, it works for other Symantec products that support Single Sign-on, in addition to Email Security.cloud.

Differences between Symantec account(Okta) and Federated users

	Symantec account (Okta)	Federated
Password Reset	Okta contains some password reset options. If they fail then Support need to locate the user in Okta and reset the password	The user will need to contact his internal support team to reset their password in their IDP
2/MFA	Okta supports email, text and something else. VIP can be added, but would just be another method that could be used and not one that must be used	The customer is in complete control of login policy and can choose whether or not to enforce MFA for whichever method they like.
Password/Login Policy	All users operate under the same policy. Exceptions can be made by email domain, but this is often avoided as it would likely result in increased support calls	The customer is in complete control of their policy
Starters/leavers	Customers have no control over Okta users, but do have control over User Management and can remove user's access there	Adding or deleting a user from the IDP will directly affect their access to ClientNet. At the moment new users will need to have roles assigned in User Management before they can login but future functionality will allow that to be driven by IDP roles too.
Authorization	All authorization is controlled through User Management by the customer admin	Currently all authorization is controlled through User Management by the customer admin but future functionality will allow that to be driven by IDP roles too, so all ClientNet access will be driven by the customer IDP.

Configuring federation with a partner IdP

You can configure federation with your own IdP, provided Okta supports it. See the Okta website at Okta.com to confirm that your partner IdP is supported.

Two options are available:

1. Self-Service setup: Directly by the customer through product (like SES, CWP) - info here. Customer needs to have either product.

2. Setup aided by support: In case the customer doesn't have SES or CWP, then Federation with a partner IdP must be initiated by opening a support ticket with Broadcom support. You can do this from within ClientNet by clicking the Support 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:

1. 1. 1. Email address
         • the claim/attribute name that represent the email address.
      2. First Name
         • the claim/attribute name that represents the first name.
      3. Last Name
         • the claim/attribute name that represents the last name.
      4. Groups
         • the claim/attribute name that represents groups. A list of security/access groups to which this user should belong.
      5. Partner/User-Id
         • the claim/attribute name that represents Partner/User-id. The unique user ID in the federated IdP. It may be represented by an actual user id attribute, or be the same as an email address for example, it depends on the IdP settings.

For example:

• • • • example.org
      • Fedetation_data.xml (file)
      • Email
      • FirstName
      • LastName
      • Groups
      • PartnerUserId

or another example (some IdP use URLs as their claim/attribute name):

• • • • example2.org
      • Fedetation_data.xml (file)
      • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
      • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
      • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
      • http://schemas.microsoft.com/ws/2008/06/identity/claims/groups
      • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

Now a wrong set of data:

• • • • example3.org
      • Fedetation_data.xml (file)
      • [email protected] > not a valid attribute, value instead provided. 
      • John > not a valid attribute, value instead provided.
      • Doe > not a valid attribute, value instead provided.
      • In the email cloud must have full access > not a valid attribute, statement instead provided. 
      • user.userprincipalname [nameid-format:emailAddress] > not a valid attribute, value instead provided. 

Attributes or variables may also be linked to urls. Check with the support of your IdP provider for assistance.

Example of what the metadata file may look like or contain:
  <samlp:AuthnRequest
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
    ID="_7171b0b2-19f2-4ba2-8f94-24b5e56b7f1e" 
    IssueInstant="2014-01-30T16:18:35Z" 
    Version="2.0" 
    AssertionConsumerServiceIndex="0" >
        <saml:Issuer>urn:federation:MicrosoftOnline</saml:Issuer>
        <samlp:NameIdPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/>
  </samlp:AuthnRequest>

• Broadcom Support will then provide the corresponding Audience and ACS urls for handshake completion on your IdP.
• Test the federated login with a few users.
• Do not enable Federated login only without proper validating and configuring all users that require access to the ClientNet portal.

Migrating existing ClientNet users to SSO/federation

When an existing user signs on 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/federated accounts. The wizard detects information about the user’s current authentication status, and walks the user through addressing these situations:

• • Duplicate – The user has a shared account, 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. This option aligns more for shared user logins, like for example a common user for a support team, here we’d recommend creating a duplicate of the user and link it to your own corp email address.
  • Link accounts – The user has a Symantec (federated) account, link this ClientNet account to the user’s Symantec Account, this shows if both have the same email address.
  • Link to Other – Alternative, if you’ve an existing Symantec account, for example that you already use for a different Symantec product, and you can choose to link the access to Email.cloud to your existing Symantec account user using a different email address.
  • Create New – If you’ve never used Symantec Account as a login method, then use this option to create your Symantec account user. The username will be the email address linked to the user you just tried to login as.
    • Takes the user to okta page to create the password and security password reset question
  • Decide Later – This is a temporary option for the time being, it allows you to defer the migration. You’ll be asked again on the next login.

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.

This option helps reduce the number of separate logins. Take for example a Partner A that has 3 Email.cloud customers. In each customer, partner A has created a local user linked to their support team, using the same support email. Via account linking, this is offered when logging in to the account, a wizard will find the common email across the 3 users and offer to link them. The partner can then link all 3 users, and share the same login via Okta or Federation. This will provide an easy account switch option icon on the top right section, allowing the support user to switch between the customer accounts without the need to logout and log back in.

Creating federated accounts for new ClientNet users

Users who are new to ClientNet must have accounts created for them by an administrator. All new or newly federated users must also have roles assigned by a ClientNet portal administrator.

Creating a new user

1. 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 full name, login name, email address, language, and time zone for the user.
   4. Under the Password heading, enter your Administrator password and then enter a new password for the user.
   5. 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.
   6. Specify whether the user is permitted to manage other users. (Choose Yes if the user you are adding is an administrator.)
   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. 1. In the portal, navigate to Dashboard > Administration > User Management.
   2. Selected the user created above
   3. Click the User roles tab.
   4. Click Use standard role or Custom Role.
   5. Select the role type to apply for this user.
   6. Click Add role.
      The role is now listed in the User roles tab.
   7. Click Save and Exit.

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 disables 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.

What IdPs are supported?

• Apple
• Azure AD
• Facebook
• Google
• LinkedIn
• Microsoft
• Okta to Okta
• OpenID Connect
• SAML 2.0

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.

I’m already using federated SSO (via Okta) with other Symantec products. Do I need to re-register my IdP?

There’s no need to re-register your IdP again, it's tied to the already registered corporate domain. In this instance you need to ensure the users in ClientNet are all set up properly and linked to the right email addresses used by your federated login.

I was using SSO via Norton Secure Login (NSL), can I continue to use it?

Yes, NSL can be used as a 3rd party IdP, as it supports SAML. This would be the way NSL would interact with Okta.

Disconnect portal link or account link?

During the transition period, any login made to a service account via SSO, will change it to a portal user. When an account becomes connected and starts sharing a single log in, it may be required to sever the link during this stage. When logged in with as the user you wish to disconnect, click on the profile icon found in the top right section. And click on Disassociate Login, save and exit. This will revert the user back to service type user.

Where to get the xml metadata file?

The location and the how will vary from IdP to IdP, our recommendation in this instance is to for the customer to reach out to the support of their respective IdP. The Okta page provides some help, but it’s best for the customer to query their own IdP support.

As a user, can I use Symantec Account via Okta and Federation at the same time?

Only one login method is permitted. If your Email.cloud customer account has adopted User Federation, and you attempt to login using your email address, you’ll be taken to the SSO page of your IdP service.

The account exists in Email.cloud as a “portal user”, if it is deleted from Email.cloud will this delete them from the Broadcom Okta portal?

No, it will not delete the Symantec Account user if the Email.cloud user is deleted. The link is severed however, and the Symantec account user can no longer access Email.cloud service.

Where do I find the attributes for the mapping?

Similar to the xml file query above, here it’s best for the customer to inquire their IdP support directly for assistance, as again it varies from IdP to IdP.

What happens if the Audience and ACS url provided to the customer don’t work?

The URLs themselves are correct and valid. The issue we have is likely caused by incorrect attributes. That is, the attributes given to Support generate the IdP link don't match with actual attributes the customer IdP sends during with authentication process. A 400 error will be issued, message Error code: General_NonSuccess. Here the customer would need to confirm the data provided is accurate, ensure the attributes are correct. This validation is recommended to be carried out with the customer’s IdP support.

As a way of diagnosing the issue, it's possible to see which attributes are sent, for this its required to capture a HAR file of the session/steps taken up until the error page.

Clear the cache on all of the involved URLs before starting the process.
 
To generate the HAR file for Chrome

1. 1. Open Google Chrome and go to the page where the issue is occurring.
   2. Look for the vertical ellipsis button and select More Tools > Developer Tools or Ctrl + Shift + I / Command + Option + I
   3. From the panel opened, select the Network tab.
   4. Look for a round Record button in the upper left corner of the tab, and make sure it is red. If it is grey, click it once to start recording.
   5. Check the box Preserve log.
   6. Click the Clear button to clear out any existing logs from the Network tab.
   7. Reproduce the issue that you were experiencing before, while the network requests are being recorded.
   8. Once you have reproduced the issue, right-click anywhere on the grid of network requests, select Save as HAR with Content, and save the file to your computer.
   9. Upload your HAR file to your ticket or attach it to your email so that our Support team can analyze

To generate the HAR file for Firefox

1. 1. Open Firefox and go to the page where you are experiencing trouble.
   2. Select the Firefox menu (three horizontal parallel lines) at the top-right of your browser window, then select Web Developer > Network or Ctrl + Shift + E / Command + Option + E
   3. The Developer Network Tools opens as a docked panel at the side or bottom of Firefox. Click the Network tab.
   4. Click on the gear icon to the right and select "Persist logs"
   5. The recording autostarts when you start performing actions in the browser.
   6. Once you have reproduced the issue and you see that all of the actions have been generated in the Developer Network Panel (should just take a few seconds), right-click anywhere under the File column, and click on Save all as Har.
   7. Save the HAR file somewhere convenient.
   8. Upload your HAR file to your ticket or attach it to your email so that we may analyze it.

To view the contents of the HAR file, the following Google Tool can be used https://toolbox.googleapps.com/apps/har_analyzer/

Browser plugins also available to capture the SAMLResponse - https://www.samltool.com/saml_tools.php

I'm using Email quarantine, can I use my federated login?

Yes, once federation has been configured a user can access the quarantine portal using the federated login. Bear in mind that the user will need to alias any other addresses to the main federated address.

Are there Okta apps for Quarantine or Clientnet? 

There are no apps available in Okta for Email.cloud portals, to use your Symantec Account or Federated access, you are needed to access the respective URL.

• • To access the Clientnet portal use https://identity.symanteccloud.com/ and follow the respective prompts based on the account type.
  • To access Email Quarantine portal, you have to use either https://eu.quarantine.symantec.com/ or https://us.quarantine.symantec.com/ depending on where your account is provisioned with the service (locations are not interchangeable) and use the appropriate "Sign in with company account" button to login with Symantec Account/Federated user.

I've linked my clientnet user to Symantec account in the past, but never used it to login. How do I check the email address I used to link my Symantec account to ClientNet?

After SSO release, existing users will still have their regular usernames post migration (until phased out). After a user logs in (regular username), the user can go My Profile (top right icon – person). You’ll see the Symantec account email address under “Disassociate your ClientNet account from your Symantec account” which shows the associated email address/Symantec account.

As an admin how do I check the email address my user used to link their Symantec account?

As an admin, you can check if your users are using a Symantec account by going to User Management and users that have migrated will show as “[email protected] (old_username)” in the login column. The email address is the address linked to their Symantec account, and the username in ( ) the old username prior to migration.
New users created as Portal user will only have their email address as their login name. This portal user then needs to activate their Symantec account using the same email address as linked to the user in ClientNet.

Can’t login with old type usernames or Symantec account?

Possible causes

• • User in Email.cloud may be turned off disabled or deleted, check with your admin.
  • Wrong ClientNet or Symantec account password. Check the answer for password reset.
  • For Symantec account users. There’s the possibility of a mismatch between email address in ClientNet and the Symantec account. Let’s assume a Symantec account has the correct email for the user, but the user in the ClientNet was set up using the wrong email. The admin needs to create a new user in ClientNet with the right email address, due to the email address being the unique login identifier.
  • An admin has decided that all users have been properly migrated and moved to Federated login only. From here onwards any attempt via old style username or Symantec Account will be presented with Login only possible via Symantec account.

Note: Service accounts still work for schemus and API access.

Can’t login, forgot my password

Depending on the user type the password reset method will change.

Before the process starts, please clear the cookies/cache to avoid any issues with any forgotten tabs.

Determine the user type.

1. 1. A user that has only a username as the login name is a service type user, and a non migrated user. This user is still managed by the ClientNet portal, and password resets are done via the same. This is also the type of user that will continue to be used for uses such as API or Schemus access. (see option 1 below)
      
      
   2. A user that has an email address as the login name, can be either a service user or a portal user. For this user, please use the config of the same to check the type at the top. If set as a service account, password reset can be done via ClientNet, if set to portal user then password reset and respective login are via Symantec account page.
      
      
   3. A user that has an email address followed by the username in parenthesis is a user that has been migrated to a Symantec account, it is now a portal user type. This user if they forget the password to their old style username, it cannot be reset anymore. Any and all logins, as well as password resets need to be executed via the Symantec account link in the ClientNet page. (option 2 below)

NOTE: The login credentials are not interchangeable. This is something to bear in mind and crucial as this may cause you to be locked out, and lead to wrongful password reset attempts, and you as user may be using the incorrect password reset option for your user type.
I.e. A portal user cannot use their Symantec account/Federated credentials in the main ClientNet login page. Symantec account/Federated users can only login via the respective link to Symantec account - "Log in with Symantec account" that leads to https://login.broadcom.com/. Same with password resets, a Symantec account user that needs to reset the password must follow the correct steps for the portal user type.

1. Service account or old type ClientNet account, an admin on the customer side can help the user via performing local reset of the password in ClientNet. Or the user themselves via self-service:

• 1. https://identity.symanteccloud.com/ 
  2. Having trouble logging in?
  3. Pick the forgotten item , like Reset your password
  4. Input username

2. Portal user or Symantec account by Okta, this reset method requires the email address linked to the user (email address is the username).

• 1. https://identity.symanteccloud.com/
  2. Click on "Log in with Symantec account", it leads to https://avagoext.okta.com/
  3. Click on Need help signing in?
  4. Click on Forgot password?
  5. Input email address used for login
  6. Complete math question
  7. You’ll get an email with a temp password
  8. Follow the Symantec account login link in the same email
  9. Login to Symantec account with temp password
  10. You’ll be prompted to set up new Symantec account password
  11. Once completed, you can use the “Log in with Symantec account” button in the main Email.cloud page.

3. Federated users, here in its entirety it depends on the customer’s own IT/email team, as the user names and password are fully managed locally by the customer’s own IdP service/IT/Mail teams. Users need to contact their own IT/Email team.

Can’t login with federated user.

When using federated only mode, all users that require access to ClientNet need to be pre-created by the admin in ClientNet and linked to the respective email address that belongs to the user. If the user trying to login doesn’t have a ClientNet user linked to his/her email address, he/she needs to contact the admin to get one created.

The following error message is presented:
Contact your administrator
Your organization has not set up an account for [email protected]. Please contact your administrator to get it set up.

After enforcing Federated login only none of users can login

Possible causes:

• • Admin didn’t do proper validation of the user’s ability to login prior to enforcement
  • Users may have been configured with the wrong email addresses in ClientNet
  • The IdP link was not tested by the admin, and may have had incorrect attributes provided. Admin needs to redo the IdP link and ensure the data needed for a successful link is accurate
  • Client may be experiencing an issue with their IdP solution which impacts SSO.

Does Okta SSO solution used by Email.cloud offer SCIM integration?

Currently SCIM is not supported.