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.
Note: On the 13th of March the URL used for authentication for Identity Providers will be changing. Where the Identity Provider Single Sign-On URL / Single Sign On URL / Assertion Consumer Service (ACS) URL, previously as https://avagoext.okta.com/… is getting replaced with https://login.broadcom.com/…
This affects only clients who have been provisioned to use Email SSO before the 13th of March. More info can be found here: https://knowledge.broadcom.com/external/article?articleId=208340
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.
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.
Symantec account (Okta)
|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.|
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:
or another example (some IdP use URLs as their claim/attribute name):
Now a wrong set of data:
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:
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:
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.
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
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
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.
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.
Yes, NSL can be used as a 3rd party IdP, as it supports SAML. This would be the way NSL would interact with Okta.
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.
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.
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.
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.
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.
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
To generate the HAR file for Firefox
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
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.
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.
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, 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.
Note: Service accounts still work for schemus and API access.
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.
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://avagoext.okta.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:
2. Portal user or Symantec account by Okta, this reset method requires the email address linked to the user (email address is the username).
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.
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.
Currently SCIM is not supported.