.. sso.rst .. _sso-details-label: ================================== Single Sign-On (SSO) ================================== Single-Sign-On (SSO) lets users log in once with a single ID to multiple related software systems. The Security Assertion Markup Language (SAML) open standard is designed to deliver a seamless user experience through SSO flows. A *service provider (SP)* provides services to end users and rely on an *identity provider (IDP or IdP)* to verify a user's identity. SSO through SAML can be initiated by an IDP (IDP-initiated SSO) or an SP (SP-initiated SSO). .. _idp-sso-vs-sp-sso: Supported SSO Initiation Forms ============================== With the release of YubiEnterprise Services 2.4.0, both IDP- and SP-initiated SSO are supported. Console Owners can enable IDP-initiated SSO from the **YubiEnterprise Console**. For more information, see :ref:`sso-enablement`. IDP-initiated SSO ----------------- The IDP authenticates users when they present their credentials so that those users can then access other websites and applications (relying applications). The SAML flow for an IDP-initiated SSO is as follows: #. When the IDP and SP established SSO trust, they shared a private key. #. The user’s identity is sent by the IDP to the SP in the form of a SAML assertion signed with the private key. #. To retrieve the SAML Assertion securely, the IDP uses the user’s browser or a reference that the SP can use. SP-initiated SSO ---------------- Service providers rely on an IDP to store the user's information (including attributes for the particular service requested), and make authentication decisions based on that information. SP-initiated SSO comes into play when a user tries to access an application at the SP end without having first authenticated with an IDP. In this case, the SAML flow is as follows: #. In the absence of an active browser session, the SP redirects the user to the IDP to request authentication. #. The user’s identity is sent by the IDP to the SP in the form of a SAML assertion signed with the *private* key. #. If the SP supports SSO from multiple IDPs, it can determine which IDP to use by: * Requesting the user to enter additional information. * Showing the user the list of supported IdPs so the user can select the right one. * Using a resource URL specific to a specific IDP. * Restoring an IDP cookie in the user’s browser session from initial IDP login. #. Upon receipt of the SAML assertion, the SP validates the signature using the *public* key and presents the user with its landing page as if the user had logged in with the usual credentials instead of SSO. SSO as Sole Means of Logging In =============================== SSO enablement introduces a new category of user: those who are able to log in *only* via SSO. Users added *after* SSO is enabled fall into this new category, while users enrolled *prior* to SSO enablement will still be able to log in with username and password. If SSO is disabled, none of the users added after SSO is enabled will be able to log in. For more information, see :ref:`sso-disable`. **API tokens** are not affected by SSO enablement or disablement. .. note:: Only a single organization at a time can be logged into with SSO. A user who is a member of multiple organizations cannot use SSO-logged-in sessions to switch between organizations. If a user needs to switch from one SSO-enabled organization to another, they must log out of the first organization and use the login link supplied by the SP for the second organization. See also :ref:`managing-passwords-with-sso-label`. Permissions and SSO ================================ .. table:: **Console permissions with and without SSO** +------------------+---------------------------------------------+--------------------------------------------+ || Capability || Logging in with SSO || Logging in with credentials | +==================+=============================================+============================================+ |Status || Users invited to join the Console || Users invited to join the | | || go into the ``Active`` state and || Console without SSO | | || can log in immediately via the || go into the ``Pending`` state | | || SP’s SSO login link. || until they enroll their credentials. | +------------------+---------------------------------------------+--------------------------------------------+ |Login Redirect | None: not applicable || If SSO has been enabled, users | | | || who log in using credentials will | | | || be redirected to log in via SSO. | +------------------+---------------------------------------------+--------------------------------------------+ |Console Operations|| All are permitted (for example shipment || No operations other than | | || request creation, listing POs, inviting || configuring SSO | | || users etc.) except configuring SSO and || (by Console Owner) and | | || updating credentials. || updating credentials are | | || || permitted. | +------------------+---------------------------------------------+--------------------------------------------+ |Credential Update || Not permitted; credential || All roles can update their | | || management page is inaccessible. || credentials: change password, | | || || edit, delete, and add new | | || || YubiKeys. | +------------------+---------------------------------------------+--------------------------------------------+ |SSO Configuration | Not permitted for any role. || Console Owners may | | | || configure SSO. | +------------------+---------------------------------------------+--------------------------------------------+ This permissions setup prevents Console Owners who have forgotten their passwords logging in via SSO, then disabling or misconfiguring SSO and inadvertently locking themselves out. .. _sso-enablement: SSO Enablement ============== The sections below describe how to configure and enable SSO for different identity providers. Console Owners can enable IDP-initiated SSO by logging in to the **Console** with credentials, going to **Settings > SSO**, and selecting **Allow IDP initiated single sign-on**. .. image:: /graphics/sso-enablement.png :width: 800 Requirements ------------ To enable SSO integration you need to: * Use SAML 2.0 with Azure AD or Okta or Google Workspace as your IDP. Other IDPs are likely to be compatible, but are not supported. For more information, see :ref:`sso-tab-label`. * Have owner, admin, or super-admin access to the SSO app in your IDP account for permissions to manage the SAML configuration and users. * Know how to enable, edit and disable your IDP's SSO offering. * Be able to share the SSO link with the Console users in your organization out-of-band after SSO is enabled, this is not something that the system does automatically. * Be a Console Owner in the Console. * Be able to log in to the Console with username/password and a registered YubiKey (via credentials, not SSO). .. _sso-limitations: Known Limitations ----------------- * Since Console users invited *after SSO enablement* are not required to have username and password, they will not be able to log in if SSO access is disabled. These users must be reset to be able to log in using credentials. Resetting a user triggers the system to send the user an email directing them to reset their username/password and register a YubiKey. See :ref:`sso-disable`. .. LAAS-5937, LAAS-5948 * Google Workspace cannot support both the SP-initiated and the IDP-initiated ACS URL at the same time. It is also not possible to set up two different SAML Apps in the same Google Workspace, because Google Workspace enforces SP EntityID uniqueness across all SAML Apps in the workspace. When IDP-initiated SSO is enabled with the Google Workspace SAML application, the IDP-initiated SSO ACS URL (``/realms/y4o-azad/broker/sso/endpoint/clients/idp-initiated``) must be configured as the ACS URL in order for the Google Dashboard link to work. When the Google Workspace SAML application is configured with this URL, the IDP will not work with the SP-Initiated flow since the `Reply URL (ACS)` endpoint does not match what is configured above. Enabling SSO with Azure AD =========================== This section describes how to enable SSO between Azure AD and the YubiEnterprise Console. These instructions assume that your company's SAML application has already been created in Azure AD. .. LAAS-5949 .. Note:: The Azure AD SAML Enterprise Application can be made to work with both the SP-initiated and IDP-initiated flows. Configure both the IDP-initiated ACS URL and the SP-initiated ACS URL as valid reply URLs. Make sure to mark the IDP-initiated URL as default. .. _copy-azure-ent-id: Copy Entity ID from Console to Azure AD ----------------------------------------------------- :Step 1: Log in to the **Console** as Console Owner using credentials (password and MFA), and go to **Settings** > **SSO**. The **Configure SAML Single Sign-On** page appears. Click the copy icon at the end of the **EntityID/Identifier** field in section **1**. .. image:: /graphics/config-sso-saml.png :width: 500 :Step 2: Log in to your Azure tenant https://portal.azure.com/signin/index/. :Step 3: Set up the new application in Azure AD (note that this does not mean "create the new application") by going to **Manage Azure Active Directory** and clicking **View**. .. image:: /graphics/azure-ad-manage.png :width: 800 Your company's **Overview** page for Azure AD appears. :Step 4: From the menu on the left-hand side, select **Enterprise Applications**. Your company's Overview page for all applications appears. :Step 5: From the list in the center pane, select the appropriate SAML application. The **Overview** page for that application appears. .. image:: /graphics/saml-overview.png :width: 800 :Step 6: Click **Get started** in the second box **Set up single sign on**. The **[Name of your organization's enterprise application] SAML | SAML-based Sign-on** page appears. .. image:: /graphics/saml-based-sign-on.png :width: 800 :Step 7: Click the Edit icon for **1 Basic SAML Configuration**. The **Basic SAML Configuration** window appears. .. image:: /graphics/basic-saml-config.png :width: 800 :Step 8: Under **Identifier (Entity ID)**, click **Add identifier**. A new field appears. .. image:: /graphics/edit-basic-saml-config.png :width: 800 :Step 9: Paste what you copied from the Console (in step 1) into the **Identifier (Entity ID)** field in Azure. If you select **Default**, this will be the primary identifier sent for IDP-initiated SAML responses. :Step 10: Save your settings by clicking **Save** in the top left corner of the **Basic SAML Configuration** Edit window. Copy Reply URL from Console to Azure AD ---------------------------------------------------- :Step 1: Log in to the **Console** as Console Owner using credentials (password and MFA), and go to **Settings** > **SSO**. The **Configure SAML Single Sign-On** page appears. Click the copy icon at the end of the **Reply URL (ACS)** field in section **1**. .. image:: /graphics/config-sso-saml.png :width: 500 :Step 2: Unless you are already logged into Azure and on the **Basic SAML Configuration** Edit window, log into your Azure tenant https://portal.azure.com/signin/index/ and perform steps 2-7 in :ref:`copy-azure-ent-id` above. :Step 3: Under **Reply URL (Assertion Consumer Service URL)**, click **Add reply URL**. A new field appears. .. image:: /graphics/add-reply-url.png :width: 800 :Step 4: Paste what you copied from the Console's **Reply URL (ACS)** field (in "Step 1") into the **Reply URL (Assertion Consumer Service URL)** field in Azure. If you select **Default**, this will be primary and IDP-initiated SAML responses will be sent to this reply URL. :Step 5: In Azure, save your settings by clicking **Save** in the top left corner of the **Basic SAML Configuration** Edit window. Copy Login URL & Azure AD Identifier from Azure to Console ---------------------------------------------------------------------------- :Step 1: Unless you are already logged into Azure and on the **Basic SAML Configuration** Edit window, log into your Azure tenant https://portal.azure.com/signin/index/ and perform steps 2-7 in :ref:`copy-azure-ent-id` above. :Step 2: In Azure, in section **4 Set up [your company's] SAML**, click the copy icon at the end of the **Login URL** field. .. image:: /graphics/set-up-company-saml.png :width: 800 :Step 3: Log in to the **Console** as Console Owner using credentials (password and MFA), and go to **Settings** > **SSO**. The **Configure SAML Single Sign-On** page appears. Paste the content from the **Login URL** field in Azure into the **IDP login URL** field in section **2**. .. image:: /graphics/config-sso-saml-step2.png :width: 800 :Step 4: Go back to Azure, and in section **4 Set up [your company's] SAML**, click the copy icon at the end of the **Azure AD Identifier** field. .. image:: /graphics/set-up-company-saml.png :width: 800 :Step 5: In the Console, in **Settings** > **SSO**, on the **Configure SAML Single Sign-On** page in section **2**, paste the content from the **Azure AD Identifier** field in Azure into the **EntityID/Issuer** field. .. image:: /graphics/config-sso-saml-step2.png :width: 800 Copy X509 Certificate from Azure AD to Console -------------------------------------------------------------- :Step 1: Unless you are already logged into Azure and on the **Basic SAML Configuration** Edit window, log into your Azure tenant https://portal.azure.com/signin/index/ and perform steps 2-7 in :ref:`copy-azure-ent-id` above. :Step 2: In section 3, **SAML Certificates**, download the **Certificate (Base64)** by clicking **Download**. .. image:: /graphics/saml-certificates.png :width: 800 :Step 3: Open the file in a text editor and copy it. You do not need to to remove the header and footer lines: .. image:: /graphics/certificate.png :width: 800 :Step 4: In the Console, in **Settings** > **SSO**, on the **Configure SAML Single Sign-On** page in section **2**, paste the certificate content into the **X.509 cert (Base64)** field. (The header and footer in the file will be automatically stripped out when you save.) :Step 5: Click the **Save settings** button at the bottom of the Console page. Set Attributes & Claims in Azure AD --------------------------------------- There is always a required claim. Ensure that the name identifier format is **Email address**. :Step 1: Unless you are already logged into Azure and on the **Basic SAML Configuration** Edit window, log into your Azure tenant https://portal.azure.com/signin/index/ and perform steps 2-7 in :ref:`copy-azure-ent-id` above. :Step 2: In section 2, **Attributes & Claims**, click the Edit icon. .. image:: /graphics/2-attributes+claims.png :width: 800 :Step 3: In the **Attributes & Claims** window that appears, click the **Unique User Identifier (Name ID)** in the **Required claim** section. .. image:: /graphics/required-claim.png :width: 800 :Step 4: In the **Manage claim** window that opens, if the **Name identifier format** is not **Email address**, select it from the dropdown list. .. image:: /graphics/manage-claim.png :width: 500 :Step 5: Save your settings in Azure by clicking **Save** in the top left corner of the **Manage claim** window. The **Attributes & Claims** window reappears. :Step 6: In the **Attributes & Claims** window, directly underneath the title, click **+ Add new claim**. The **Manage claim** window appears. .. image:: /graphics/azure-add-new-claim.png :width: 800 :Step 7: In the **Manage claim** window, in the **Name** field, enter ``emailAddress``, and for **Source** leave the default setting with the **Attribute** radio button. From the **Source attribute** dropdown, select ``user.mail``. Click **Save**. The **Attributes & Claims** window reappears with your new claim listed. .. image:: /graphics/azure-listed-add-claim.png :width: 800 Verify and Save SSO Settings in Console ------------------------------------------------------- :Step 1: In the Console, look at **Settings** > **SSO** **Configure SAML Single Sign-On** to make sure that the content you pasted in is correct. :Step 2: In section **3**, copy the **SP Initiated Login URL** by clicking the copy icon at the end of it. Save the URL so that you can send it to your Console users. .. image:: /graphics/config-sso-saml-step3.png :width: 500 :Step 3: Before enabling SSO, make sure to send all users who will be enabled for it this **SP Initiated Login URL**. The same link will also be shown in the login dialog after you have enabled SSO. Add Users and Enable User Login via SSO --------------------------------------- Add users first to Azure, then to the Console. Before you can add them to your company's SAML application in Azure, the users must be added to your company's Azure AD instance at the top level. If needed, ensure you have the permissions in Azure to have groups available for assignment. :Step 1: On your company's Overview page in Azure, from the menu on the left under **Manage**, select **Users**. On the **Users** page, the entire list of your company's users appears. .. image:: /graphics/azure-overview-manage-users.png :width: 800 :Step 2: To add entirely new users to Azure as opposed to adding them to the SAML organization, click **New user** at the top of the page and follow the directions provided in the subsequent pages. Otherwise select the users for whom you are enabling SSO by clicking on the checkbox next to the respective **Display name**. :Step 3: From **[your company's] SAML Overview** page, click **Assign users and groups**. The **Users and groups** window appears. .. image:: /graphics/2-assign-users.png :width: 800 :Step 4: Click **Add user/group** at the top of the window. The **Add Assignment** screen appears. Under **Users**, click **None Selected** to display a list of your total users in Azure. .. image:: /graphics/add-assignment.png :width: 800 :Step 5: Select the checkboxes for the requisite users, then click the **Select** button. :Step 6: As Console Owner or Admin, log in to the Console, go to **Settings** > **Users**, and add users as needed from Azure to the Console. .. _okta-intro-label: Enabling SSO with Okta ======================= This section describes how to enable SSO between Okta and the YubiEnterprise Console. These instructions assume that your company's SAML application has already been created in Okta. Create App Integration ----------------------------- :Step 1: Log in to the **Console** as Console Owner with user name and password, and go to **Settings** > **SSO**. The **Configure SAML Single Sign-On** page appears. This is the location from which you will be copying information. .. image:: /graphics/config-sso-saml.png :width: 500 :Step 2: Log in to your company's Okta tenant https://developer.okta.com/login/ as Admin, and navigate to **Applications > Applications**. The Applications page appears on the right. .. image:: /graphics/okta-applications-applications-1.png :width: 800 :Step 3: Click **Create App Integration**. The **Create a new app integration** window appears. .. image:: /graphics/okta-create-app-integ.png :width: 800 :Step 4: Select **SAML 2.0** and click **Next**. The **Create SAML Integration** window appears. .. image:: /graphics/okta-create-saml-integ-gen-tab-1.png :width: 800 :Step 5: On the **1. General Settings** tab, enter the appropriate name in the **App name** field, make any other necessary settings and click **Next**. The **Configure SAML** tab of the **Create SAML Integration** window appears. .. image:: /graphics/A-saml-settings-1.png :width: 800 Copy Entity ID from Console to Okta ----------------------------------- 1. In the Console **Settings > SSO** page from Step 1 in :ref:`okta-intro-label`, click the copy icon to copy the **EntityID/Identifier** from the Console. 2. Paste it into the **Audience URI (SP Entity ID)** field in Okta's **Configure SAML** tab. .. image:: /graphics/okta-create-saml-integ-saml-tab-1.png :width: 800 Copy Reply URL from Console to Okta ------------------------------------ 1. In the Console **Settings > SSO** page from Step 1 in :ref:`okta-intro-label`, click the copy icon to copy the **Reply URL (ACS)** from the Console. 2. Paste it into the **Single sign-on URL** field in Okta's **Create SAML Integration** window on the **Configure SAML** tab. Enable the checkbox for **Use this for Recipient URL and Destination URL**. .. image:: /graphics/okta-create-saml-integ-saml-tab-2.png :width: 500 Set Name ID Format, Application Username, and Attribute Statement ----------------------------------------------------------------- :Step 1: In Okta, still in the **General** section on the **A SAML Settings** tab, from the **Name ID format** dropdown, select **EmailAddress**. :Step 2: From the **Application username** dropdown, select **Email**. .. image:: /graphics/okta-name-id-format+app-username.png :width: 800 :Step 3: Scroll down to the **Attribute Statements (optional)** section, and * Under **Name**, enter ``emailAddress`` * Leave the **Name format** unspecified * Under **Value** enter ``user.email``. .. image:: /graphics/okta-attribute-statements.png :width: 800 :Step 4: Scroll down to the bottom of the tab and click **Next**. The **Feedback** tab appears. :Step 5: On the **Feedback** tab under **Create SAML Integration**, select either: * **I'm an Okta customer adding an internal app** or * **I'm a software vendor. I'd like to integrate my app with Okta**, Provide feedback (optional) and click **Finish**. The **Sign On** tab for your application appears. .. image:: /graphics/okta-sign-on.png :width: 800 Copy IDP SSO URL & X509 Certificate from Okta to Console --------------------------------------------------------------- :Step 1: On the bottom right of Okta's **Sign On** tab, click the **View SAML setup instructions** tab. .. image:: /graphics/okta-view-saml-setup.png :width: 800 The **How to Configure SAML 2.0 for [name of your] Application** window appears. .. image:: /graphics/okta-how-to-conf-saml-2.0.png :width: 800 :Step 2: Still in Okta, copy the content of the **Identity Provider Single Sign-On URL:** to the **IDP login URL** field in the Console. .. image:: /graphics/config-sso-saml-step2-okta.png :width: 800 :Step 3: From the Okta **The following is needed to configure [application name]** window, copy the **Identity Provider Issuer** to the Console's **EntityID/Issuer**. :Step 4: In Okta, click **Download certificate** under **X.509 Certificate**, then paste the content to the Console's **X.509 cert (Base64)** field. :Step 5: In the Console, click **Save settings**. :Step 6: From the Console, copy the **SP Initiated Login URL** and send it to your users. Add Console Users to Okta's SAML App Integration ------------------------------------------------ Users for whom you intend to enable SSO must first be in Okta to be available for adding to the application integration. For information on how to add users, see the Okta documentation. 1. In Okta, navigate to **Applications > Applications** and click **Assign Users to App**. The **[name of app]** page for your app appears. .. image:: /graphics/bite-assignments-1.png :width: 800 2. Assign Console organization members as a group or as individuals. 3. In the Console, enable SSO. .. LAAS-5963 Enable IDP- and SP-initiated SAML Flows --------------------------------------------- This configuration enables both the IDP- and SP- initiated SAML flows for Okta. This subsection assumes that you are familiar with the instructions for IDP-initiated SAML flow with Okta. :Step 1: In the **Console** > **Settings > SSO**, select **Allow IDP initiated single sign-on** to enable, and copy the **IDP initiated login URL (ACS)**. .. image:: graphics/okta-idp-initiated-1-1.png :width: 800 :Step 2: In Okta, go to **App General > SAML Settings > Edit > Edit SAML Integration: General Settings > Configure SAML**. :Step 3: Still in Okta, paste the **IDP-initiated Login URL** from the **Console** into the **Single sign-on URL** field, click **Use this for Recipient URL and Destination URL**, then click **Next** and finally **Finish**. .. image:: graphics/okta-idp-initiated-2.png :width: 800 :Step 4: Test: in Okta, on **App General > App Embed Link**, copy the IDP-initiated login link from the **Embed link** field into your browser to verify that the link redirects you to the Console after Okta login. .. image:: graphics/okta-idp-initiated-3.png :width: 800 Start App Integration ------------------------------ To start IDP-initiated login, go to the **Okta End User Apps Dashboard** (https://.okta.com/app/UserHome) and click on the app for the Console SSO integration. .. image:: graphics/okta-end-user-apps-dashboard.png .. _google-sso-label: Enabling SSO with Google Workspace ========================================= This section describes how to enable SSO between Google Workspace and the YubiEnterprise Console. Prerequisites ------------- * Ensure that you are a Console Owner in the Console. * System role: Your Google Workspace Administrator Seed Role must be Super Admin. * Ensure you have access to the email account associated with that Google account. Procedure --------- Add a Custom SAML App ~~~~~~~~~~~~~~~~~~~~~ :Step 1: Log into the Google Admin Workspace by going to `admin.google.com/ `_ and selecting the appropriate account. :Step 2: Enter username and password for the selected account. If your company has set up Google Groups to require a YubiKey, you will be prompted to plug one in and touch it. After login, the **Admin** page appears. .. image:: /graphics/apps-before-web-and-mobile-apps.png :width: 800 :Step 3: Go to **Apps** > **Web and mobile apps**. .. image:: /graphics/admin-web-and-mobile-apps.png :width: 800 :Step 4: Create a new SAML app by clicking on the **Add app** dropdown and selecting **Add custom SAML app** (you need be Super Admin to see this option.) .. image:: /graphics/add-custom-saml-app.png :width: 800 Under the **Add custom SAML app** banner, the **1 App details** tab is displayed: .. image:: /graphics/add-custom-saml-app-app-details.png :width: 500 :Step 5: In the **1 App details** tab: * (Required) Enter a name in the **App name** field. * (Optional) Add a description in the **Description** field. * (Optional) Attach an icon for the app by clicking on the big blue button. Click **CONTINUE**. Under the **Add custom SAML app**, the **2 Google Identity Provider detail** page appears. .. image:: /graphics/g-add-custom-saml-app-google-idp-details.png :width: 800 Configure the Custom SAML App ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Copy and paste information between the Google **Add custom SAML app** and the Console **Configure SAML Single Sign-On** pages, have them open side-by-side in two browser windows. :Step 1: Log in to the Console as Console Owner with username, password, and YubiKey. Go to **Settings** > **SSO** to open the the SSO configuration page. .. image:: /graphics/configure-sso-saml-google.png :width: 600 :Step 2: Enter the following values from Google's **2 Google Identity Provider detail** page into the Console's SSO configuration form, transferring them from the fields listed in the table: .. table:: +-----------------------+------------------------------+ |Google |YubiEnterprise Console | +=======================+==============================+ |SSO URL |IDP login URL (section 2) | +-----------------------+------------------------------+ |Entity ID |EntityID/Issuer (section 2) | +-----------------------+------------------------------+ |Certificate |X.509 cert (Base64)(section 2)| +-----------------------+------------------------------+ On the Console's **Configure SAML Single Sign-On** page, click **Save settings**. :Step 3: In Google, in the **Add custom SAML app** screen, click **CONTINUE**. The **3 Service provider details** window appears. .. image:: /graphics/3-service-provider-details.png :width: 800 :Step 4: In Google, in the **3 Service provider details** window, enter the following values from the Console into Google's form, transferring them from the fields listed in the table: .. table:: +-------------------------------------------------+----------------------------+ |Google |YubiEnterprise Console | +=================================================+============================+ |ACS URL |Reply URL (ACS) (step 1) | +-------------------------------------------------+----------------------------+ |Entity ID |EntityID/Identifier (step 1)| +-------------------------------------------------+----------------------------+ |Start URL - leave blank | | +-------------------------------------------------+----------------------------+ |Name ID format - set **EMAIL** | | +-------------------------------------------------+----------------------------+ |Name ID - leave Basic Information > Primary email| | +-------------------------------------------------+----------------------------+ :Step 5: In Google, in the **3 Service provider details** screen, click **CONTINUE**. The **4 Attribute Mapping** page appears (with *Attributes* and *Group membership (optional)*. Skip these steps by clicking **FINISH**. The page for your new SAML app appears. .. image:: /graphics/bite-me-i-am-so-sure.png :width: 800 :Step 6: In Google, ensure that **User Access** is **ON for everyone** by clicking on the caret in the upper right corner of the **User access** section. .. image:: /graphics/the-caret.png :width: 800 The **Service Status** window opens. Toggle the service status radio control to **ON for everyone** and click **SAVE**. .. image:: /graphics/service-status.png :width: 800 :Step 7: In the Console, click **Save settings** and **Enable SSO** (unless already enabled). Troubleshooting ~~~~~~~~~~~~~~~ * **Issue**: Changing the ACS URL in an existing Google IDP configuration does not appear to be successful even after waiting a significant amount of time. * **Workaround**: Start over. Delete your **Web and mobile app** and start again. * **Issue**: Sometimes the Google site displays the 500 error after SSO configuration. * **Workaround**: Update the **Entity ID** with a trailing forward slash "/". If you already have such a slash, remove it. * **Issue**: Sometimes Google presents the message "Service is not configured for this user". * **Workaround**: Update the **Entity ID** with a trailing forward slash "/". If you already have such a slash, remove it. .. _yed-duo-sso-label: Enabling SSO with Duo ======================== This section describes how to enable SSO between Duo and the YubiEnterprise Console. Note that unlike the other SAML integrations described above, Duo is not the IDP for the users. The following instructions assume that Duo is configured with Azure as the IDP, so those steps are not included. Prerequisites -------------- * Ensure that Duo’s IDP is configured (Azure for this environment). * Ensure that you are a Console Owner in the Console. * As Console Owner, add the SSO users to your organization in the Console, see :ref:`add-users-label`. Each user's email address must match the email address used for that user in Duo and in Azure. Procedure ---------- To copy and paste information between the Duo and the Console configuration pages, have them open side-by-side in two browser windows. :Step 1: As administrator, log in to the Duo Tenant Admin portal: https://admin.duosecurity.com. .. image:: /graphics/duo-login.png :width: 300 :Step 2: **Add the Console (YubiEnterprise Delivery) application in Duo.** Go to **Applications** > **Protect an Application** > **YubiEnterprise Delivery** > **Protect**. .. image:: /graphics/duo-add-app.png :width: 800 :Step 3: Log in to the Console with the Console Owner role. :Step 4: **Configure Console SSO to IDP (Duo).** In the Console, go to **Settings > SSO** to open the **SAML Single Sign-On** page. Copy the **EntityID/Identifier** field from section **1** in the Console to the **EntityID/Identifier** field in the Duo Service Provider section. .. image:: /graphics/config-sso-saml-duo1.png :width: 500 *Console configuration section* .. image:: /graphics/duo-configure-service-provider.png :width: 500 *Duo configuration section* :Step 5: **Configure IDP (Duo) to SP (Console).** * Copy the **EntityID/Identifier** field from the Duo application configuration Metadata section to the **EntityID/Issuer** field in section **2** in the Console configuration page. * Copy the **IDP login URL** from Duo to the **IDP login URL** field in the Console. * In Duo, download the **Certificate**, open the file with a text editor, copy the content and paste it into the **X.509 cert (Base64)** field in the Console. .. image:: /graphics/duo-metadata-fields.png :width: 800 *Duo configuration section* .. image:: /graphics/config-sso-saml-duo2.png :width: 800 *Console configuration section* :Step 6: **Save settings and enable SSO in the Console.** Ensure to click **Save settings** and **Enable SSO** before closing your browser. .. image:: /graphics/duo-enable-sso.png :Step 7: **Configure Duo application attribute mapping.** To configure a Duo attribute other than **Email Address** as the email address attribute sent to the Console in the SAML response, return to the Duo application configuration screen Service Provider section, check the box for **Custom attributes**, and then select the attribute to send as the email address attribute. .. image:: /graphics/duo-saml-response.png :Step 8: **Configure Duo application policy.** Duo policies control how users authenticate to specific applications. Steps 8 and 9 ensure that MFA is enforced, and YubiKeys are enabled as Webauthn authentication method. These policies can be configured globally, or per application. If other applications are already being protected with Duo, ensure that the following settings can apply to all applications, or consider creating a unique Application policy for the Console. See the `Duo documentation `_. a. To configure global policies, click **Edit Global Policy** in the Duo application configuration page. .. image:: /graphics/duo-global-policy.png :width: 500 b. In the New User Policy section, ensure the **Require enrollment** option is selected. (Optional) if the IdP is forcing 2FA, click **Bypass 2FA** in the Authentication Policy section. To force 2FA in Duo (not relying on the IdP), click **Enforce 2FA**. .. image:: /graphics/duo-edit-global-policy.png :width: 800 :Step 9: **Ensure hardware tokens are selected.** In Duo, scroll down to the **Authentication methods** section, and ensure the **Hardware tokens** option is selected.  .. image:: /graphics/duo-hardware-tokens.png :width: 800 :Step 10: **Save the global policy.** In Duo, click **Save Policy** at the bottom of the Global Policy configuration page. :Step 11: **Save the application configuration.** In Duo, click **Save** at the bottom of the application configuration page. .. _sso-tab-label: Enabling SSO for Other IDPs =========================== To try out SSO for identity providers that Yubico does not explicitly claim to support, go to **Settings** > **SSO** > **Configure SAML Single Sign-On**, and fill in the configuration fields. .. image:: /graphics/configure-sso-saml-google.png :width: 500 .. Note:: Be aware that the field labels vary depending on the IDP. For examples of these variances, look at the instructions for supported IDPs Microsoft Azure, Okta, and Google Workspace. .. _sso-disable: Disabling SSO ============= To disable SSO, in the **Console**, go to **Settings** > **SSO**. In the **Configure SAML Single Sign-On** page click the **Disable SSO** button. .. LAAS-4128 Users added *after* SSO was enabled will not be able to login once SSO is disabled. Therefore you need to determine which users need to be enabled to log in with credentials again. To see which users have credentials, log in to the Console as Console Owner with credentials and go to **Settings > Users**. The **MFA** column on the page indicates which users have credentials. .. image:: graphics/settings-tab3.png :width: 800 To enable users added after SSO enablement to enroll credentials and log in again, reset them as described in :ref:`account-reset-label`. ------------------------------------- To file a support ticket for YubiEnterprise Delivery, click `Support `_.