Configure the standard authentication type

For Standard (default), federate your third-party SAML 2.0 identity provider (such as Okta or Ping) directly with your portal.

The Standard identity type can support service-provider-initiated (SP-initiated) and identity-provider-initiated (IdP-initiated) sign-in flows with your SAML 2.0 compliant IdP.

Step 1: Start to configure your identity provider on WorkSpaces Secure Browser

Complete the following steps to configure your identity provider:

1. On the Configure identity provider page of the creation wizard, choose Standard.

2. Choose Continue with Standard IdP.

3. Download the SP metadata file, and keep the tab open for individual metadata values.

   • If the SP metadata file is available, choose Download metadata file to download the service provider (SP) metadata document, and upload the service provider metadata file to your IdP in the next step. Without this, users won't be able to sign in.

   • If your provider doesn't upload SP metadata files, manually enter the metadata values.

4. Under Choose SAML sign-in type, choose between SP-initiated and IdP-initiated SAML assertions, or SP-initiated SAML assertions only.

   • SP-initiated and IdP-initiated SAML assertions allow your portal to support both types of sign-in flows. Portals that support IdP-initiated flows allow you to present SAML assertions to the service identity federation endpoint without requiring users to launch a session by visiting the portal URL.

     • Choose this to allow the portal to accept unsolicited IdP-initiated SAML assertions.

     • This option requires a default Relay State to be configured in your SAML 2.0 Identity Provider. The Relay state parameter for your portal is in the console under IdP initiated SAML sign in, or you can copy it from the SP metadata file under <md:IdPInitRelayState>.

     • Note

       • The following is the format of the relay state: redirect_uri=https%3A%2F%2Fportal-id.workspaces-web.com%2Fsso&response_type=code&client_id=1example23456789&identity_provider=Example-Identity-Provider.

       • If you copy and paste the value from the SP metadata file, make sure that you change & to &. & is an XML escape character.

   • Choose SP-initiated SAML assertions only for the portal to only support SP-initiated sign in flows. This option will reject unsolicited SAML assertions from IdP-initiated sign-in flows.

   Note

   Some third-party IdPs allow you to create a custom SAML application that can deliver IdP-initiated authentication experiences leveraging SP-initiated flows. For example, see Add an Okta bookmark application.

5. Choose whether you want to enable Sign SAML requests to this provider. SP-initiated authentication allows your IdP to validate that the authentication request is coming from the portal, which prevents accepting other third-party requests.

   1. Download the signing certificate and upload it to your IdP. The same signing certificate can be used for single logout.

   2. Enable signed request in your IdP. The name might be different, depending on the IdP.

      Note

      RSA-SHA256 is the only request and default request signing algorithm supported.

6. Choose whether you want to enable Require encrypted SAML assertions. This allows you to encrypt the SAML assertion that comes from your IdP. It can prevent data from being intercepted in SAML assertions between the IdP and WorkSpaces Secure Browser.

   Note

   The encryption certificate is not available at this step. It will be created after your portal launches. After you launch the portal, download the encryption certificate and upload it to your IdP. Then, enable assertion encryption in your IdP (the name might be different, depending on the IdP.

7. Choose whether you want to enable Single Logout. Single logout allows your end users to sign out of both their IdP and WorkSpaces Secure Browser session with a single action.

   1. Download the signing certificate from WorkSpaces Secure Browser and upload it onto your IdP. This is the same signing certificate used for Request Signing in the previous step.

   2. Using Single Logout requires you to configure a Single Logout URL in your SAML 2.0 identity provider. You can find the Single Logout URL for your portal in the console under Service provider (SP) details - Show individual metadata values, or from the SP metadata file under <md:SingleLogoutService> .

   3. Enable Single Logout in your IdP. The name might be different, depending on the IdP.

Step 2: Configure your identity provider on your own IdP

Open a new tab in your browser. Then, complete the following steps with your IdP:

1. Add your portal metadata to your SAML IdP.

   Either upload the SP metadata document that you downloaded in the previous step to your IdP, or copy and paste the metadata values into the correct fields in your IdP. Some providers do not allow file upload.

   The details of this process can vary between providers. Find your provider's documentation in Guidance for specific IdPs for help on how to add the portal details to your IdP configuration.

2. Confirm the NameID for your SAML assertion.

   Make sure your SAML IdP populates NameID in the SAML assertion with the user email field. NameID and user email are used for uniquely identifying your SAML federated user with the portal. Use the persistent SAML Name ID format.

3. Optional: Configure the Relay State for IdP-initiated authentication.

   If you chose Accept SP-initiated and IdP-initiated SAML assertions in the previous step, follow steps in step 2 of Step 1: Start to configure your identity provider on WorkSpaces Secure Browser to set the default Relay State for your IdP application.

4. Optional: Configure Request signing. If you chose Sign SAML requests to this provider in the previous step, follow steps in step 3 of Step 1: Start to configure your identity provider on WorkSpaces Secure Browser to upload the signing certificate onto your IdP and enable request signing. Some IdPs such as Okta might require your NameID to belong to the “persistent” type to use Request signing. Make sure to confirm your NameID for your SAML assertion by following the steps above.

5. Optional: Configure Assertion encryption. If you chose Require encrypted SAML assertions from this provider, wait until portal creation is complete, then follow step 4 in "Upload metadata" below to upload the encryption certificate onto your IdP and enable assertion encryption.

6. Optional: Configure Single Logout. If you chose Single Logout, follow the steps in step 5 of Step 1: Start to configure your identity provider on WorkSpaces Secure Browser to upload the signing certificate onto your IdP, fill in Single Logout URL, and enable Single Logout.

7. Grant access to your users in your IdP to use WorkSpaces Secure Browser.

8. Download a metadata exchange file from your IdP. You will upload this metadata to WorkSpaces Secure Browser in the next step.

Step 3: Finish configuring your identity provider on WorkSpaces Secure Browser

Return to the WorkSpaces Secure Browserconsole. On the Configure identity provider page of the creation wizard, under IdP metadata, either upload a metadata file, or enter a metadata URL from your IdP. The portal uses this metadata from your IdP to establish trust.

1. To upload a metadata file, under IdP metadata document, choose Choose file. Upload the XML-formatted metadata file from your IdP that you downloaded in the previous step.

2. To use a metadata URL, go to your IdP that you set up in the previous step and obtain its Metadata URL. Go back to the WorkSpaces Secure Browser console, and under IdP metadata URL, enter the metadata url that you obtained from your IdP.

3. When you are done, choose Next.

4. For portals where you have enabled the Require encrypted SAML assertions from this provider option, you need to download the encryption certificate from the portal IdP details section and upload it onto your IdP. Then, you can enable the option there.

   Note

   WorkSpaces Secure Browser requires the subject or NameID to be mapped and set in the SAML assertion within your IdP's settings. Your IdP can create these mappings automatically. If these mappings aren't configured correctly, your users can't sign in to the web portal and start a session.

   WorkSpaces Secure Browser requires the following claims to be present in the SAML response. You can find <Your SP Entity ID> and <Your SP ACS URL> from your portal’s service provider details or metadata document, either through the console or the CLI.

   • An AudienceRestriction claim with an Audience value that sets your SP Entity ID as the target of the response. Example:

     <saml:AudienceRestriction>
         <saml:Audience><Your SP Entity ID></saml:Audience>
     </saml:AudienceRestriction> 

   • A Response claim with an InResponseTo value of the original SAML request ID. Example:

     <samlp:Response ... InResponseTo="<originalSAMLrequestId>">

   • A SubjectConfirmationData claim with a Recipient value of your SP ACS URL, and an InResponseTo value that matches the original SAML request ID. Example:

     <saml:SubjectConfirmation>
         <saml:SubjectConfirmationData ... 
             Recipient="<Your SP ACS URL>"
             InResponseTo="<originalSAMLrequestId>"
             />
     </saml:SubjectConfirmation> 

   WorkSpaces Secure Browser validates your request parameters and SAML assertions. For IdP-initiated SAML assertions, the details of your request must be formatted as a RelayState parameter in the body of an HTTP POST request. The request body must also contain your SAML assertion as a SAMLResponse parameter. Both of these should be present if you have followed the previous step.

   The following is an example POST body for an IdP-initiated SAML provider.

   SAMLResponse=<Base64-encoded SAML assertion>&RelayState=<RelayState> 

Guidance for specific IdPs

To make sure you correctly configure the SAML federation for your portal, see the links below for documentation from commonly used IdPs.

IdP	SAML application setup	User management	IdP-initiated auth	Request signing	Assertion encryption	Single logout
Okta	Create SAML app integrations	User management	Application Integration Wizard SAML field reference	Application Integration Wizard SAML field reference	Application Integration Wizard SAML field reference	Application Integration Wizard SAML field reference
Entra	Create your own application	Quickstart: Create and assign a user account	Enable single sign-on for an enterprise application	SAML Request Signature Verification	Configure Microsoft Entra SAML token encryption	Single Sign-Out SAML Protocol
Ping	Add a SAML application	Users	Enabling IdP-initiated SSO	Configuring authentication request signing in PingOne for Enterprise	Does PingOne for Enterprise support encryption?	SAML 2.0 single logout
One Login	SAML Custom Connector (Advanced) (4266907)	Add Users to OneLogin Manually	SAML Custom Connector (Advanced) (4266907)	SAML Custom Connector (Advanced) (4266907)	SAML Custom Connector (Advanced) (4266907)	SAML Custom Connector (Advanced) (4266907)
IAM Identity Center	Set up your own SAML 2.0 application	Set up your own SAML 2.0 application	Set up your own SAML 2.0 application	N/A	N/A	N/A