This the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

  • 1:
    • 2:
      • 3:
        • 4:

          SAML (On-Prem)

          These instructions are specific to On-Premises Deployments of the Sysdig platform. If you are using the cloud-based (SaaS) Sysdig platform, refer to SAML (SaaS) instead.

          SAML support in the Sysdig platform allows authentication via your choice of Identity Provider (IdP).

          The Sysdig platform ordinarily maintains its own user database to hold a username and password hash. SAML instead allows for redirection to your organization’s IdP to validate username/password and other policies necessary to grant access to Sysdig application(s). Upon successful authentication via SAML, a corresponding user record in the Sysdig platform’s user database is automatically created, though the password that was sent to the IdP is never seen nor stored by the Sysdig platform.

          This section describes how to integrate and enable SAML with both Sysdig Monitor and Sysdig Secure.

          For specific IdP integration information, refer to:

          See also Caveats, below.

          Basic Enablement Workflow

          Step

          Options

          Notes

          1. Know which IdP your company uses and will be configuring.

          These are the IdPs for which Sysdig has performed detailed interoperability testing and confirmed how to integrate using their standard docs.

          If your IDP is not listed, it may still work with the Sysdig platform. Contact Sysdig Support for help.

          2. Decide the login flow you want users to experience (choose from three options):

          Click SAML button

          From https://HOSTNAME/ or https://HOSTNAME/secure/

          Type/bookmark a URL in browser

          Monitor:https://HOSTNAME/api/saml

          Secure: https://HOSTNAME/api/saml?product=SDS

          Log in from an IdP interface

          The individual IdP integration pages describe how to add Sysdig to the IdP interface.

          You will need your Sysdig customer number on hand. Normally 1 for on-premises.

          3. Perform the configuration steps in your IdP interface and collect the resulting config attributes.

          Collect metadata URL (or XML) and test it.

          If you intend to configure IDP-initiated login flow, have your Sysdig customer number on hand. It will be referenced in later configuration steps as CUSTOMER_ID_NUMBER. Normally 1.

          4 a. Log in to Sysdig Monitor (as "super" admin) and enter the necessary configuration information in the UI. Enable SAML as your SSO.

          4b. Log in to Sysdig Secure (as "super" admin) and repeat the above.

           

          Administrator Steps

          Configure IdP

          Select the appropriate IdP from the list below, and follow the instructions:

          UI-Based: Configure SAML in Settings

          At this time, the Authorization UI is available only for Sysdig Monitor.

          To enable baseline SAML functionality:

          Enter SAML Connection Settings

          1. Log in to Sysdig Monitor or Sysdig Secure as administrator and select Settings.

          2. Select Authentication.

          3. Select the SAML tab.

          4. Enter the relevant parameters (see table below) and click Save.

            It is strongly recommended that “Signed Assertion” and “Validate Signature” are enabled to ensure that the SAML SSO process is as secure as possible.

          Connection SettingOptionsDescriptionSample Entry
          MetadataURLThe URL provided at the end of the IdP configuration steps.
          XMLAn option that can be used for an IdP that doesn’t support extracting metadata XML via URL.
          Signed Assertionoff/onShould Sysdig check for assertions signed in responses (to assist in validating correct IdP).ON
          Email ParameteremailName of parameter in the SAML response for user email ID. Sysdig uses this to extract the user’s email from the response.email
          Validate Signatureoff/onSysdig backend should verify that the response is signed.ON
          Verify Destinationoff/onFlag to control whether Sysdig should check the “destination” field in the SAMLResponse. Recommend ON, as a security measure. May be OFF in special cases, such as a proxy in front of the Sysdig back end.ON

          Select SAML for SSO

          1. Select SAML from the Enabled Single Sign-On dropdown

          2. Click Save Authentication.

          3. Repeat entire enablement process for Sysdig Monitor or Sysdig Secure, if you want to enable on both applications.

          Script-Based: Configure SAML Using Scripts

          The configuration of the SAML feature can be viewed, updated, and deleted by the “super” Admin. A saml_config.sh helper script is available in the SSO folder at sysdig-cloud-scripts repository to assist in completing this configuration. Invoking the script with no options will display help text.

          # ./saml_config.sh
          Must specify the Sysdig App whose SAML configuration will be viewed/set
          
          Usage: ./saml_config.sh [OPTIONS]
          
          Affect SAML login settings for your Sysdig software platform installation
          
          If no OPTIONS are specified, only the help output is displayed.
          

          To use the helper script, modify env.sh to set the required values for API_TOKEN of the “super” Admin user and the URL for accessing the Sysdig platform API (which will be the same URL that your users access for the Sysdig Monitor application).

          Depending if the API_TOKEN has been obtained from the Sysdig Monitor or Sysdig Secure application UI, the settings will be applied to the relevant product.

          Initially no SAML settings are set. A initial run of the script would confirm that:

          # ./saml_config.sh
          No saml settings are set
          Run for further info: ./saml_config.sh -h
          

          Add the -s option to set the SAML configuration for a particular Sysdig application. When setting the config, you’ll also include the metadata URL you saved in the earlier IDP configuration step (-m option) and specify the name of a supported IDP configuration (-i option), which will tailor other details of your SAML configuration to the specifics of that IDP. If the configuration is successfully posted to the Sysdig platform, the new configuration will be echoed back.

          An example of creating the two separate SAML configurations for both Monitor and Secure, each using Okta IDP settings:

          # ./saml_config.sh -s -m 'https://dev-824158.oktapreview.com/app/exkfpgqiskSoGZrjE0h7/sso/saml/metadata' -i okta
          {
            "authenticationSettings": {
              "id": 1,
              "version": 1,
              "createdOn": 1547539750000,
              "type": "saml",
              "scope": "SYSTEM",
              "settings": {
                "metadataUrl": "https://dev-824158.oktapreview.com/app/exkfpgqiskSoGZrjE0h7/sso/saml/metadata",
                "metadata": null,
                "validateSignature": true,
                "emailParameter": "email",
                "signedAssertion": true,
                "verifyDestination": true,
                "createUserOnLogin": true
              }
            }
          }
          

          If you are using an IDP other than those available with the -i option, contact Sysdig Support for assistance with determining the correct settings.

          Once you’ve completed this configuration, clicking the SAML button at the login screen of the appropriate Sysdig application(s) should redirect to your IDP for authentication.

          If you wish to delete your SAML configuration, invoke the -d option. If successful, the disabled configuration will be printed.

          # ./saml_config.sh -a monitor -d
          {
            "authenticationSettings": {
              "id": 1,
              "version": 1,
              "createdOn": 1547539750000,
              "type": "saml",
              "scope": "SYSTEM",
              "settings": {
                "metadataUrl": "https://dev-824158.oktapreview.com/app/exkfpgqiskSoGZrjE0h7/sso/saml/metadata",
                "metadata": null,
                "validateSignature": true,
                "emailParameter": "email",
                "signedAssertion": true,
                "verifyDestination": true,
                "createUserOnLogin": true
              }
            }
          }
          

          Configure SAML Single Logout

          Sysdig supports SAML Single Logout (SLO).

          SLO is a feature in federated authentication where Sysdig users can sign out of both their Sysdig session (Service Provider) and associated IdP (Identity Provider) simultaneously. SLO allows you to terminate all sessions established via SAML SSO by initiating a single logout process. Closing all user sessions prevents unauthorized users from gaining access to Sysdig resources.

          SLO Process

          When a user initiates a logout, Sysdig sends a digitally-signed logout request to the IdP. The IdP validates the request and terminates the current login session, then redirects the user back to the Sysdig login page.

          Caveats

          • SLO is currently supported only in US-West and EU-Central regions.

          • Sysdig does not support HTTP Post binding for single logout, and therefore, SLO with Okta is not functional at this point.

          Configure IdP

          1. Configure logout URLs:

            • Monitor: <base_URL>/api/saml/slo/logout

            • Secure: <base_URL>/api/saml/slo/secureLogout

          2. Choose HTTP Redirect as the binding method.

            This option is an alternative to the HTTP POST method, which Sysdig does not support currently.

          3. If your IdP mandates, upload the public key for Sysdig.

            Contact Sysdig Support to retrieve the public key associated with your deployment.

            Certain IDPs, such as Azure, don’t require uploading the public key.

          Configure Sysdig

          1. Log in to Sysdig Monitor or Sysdig Secure as an administrator and select Settings.

            For on-prem deployments, log in as the super admin.

          2. Navigate to Settings > Authentication, and select SAML under Connection Settings.

          3. Enter the SAML configuration.

          4. Ensure that Enable SAML single logout is toggled on.

          5. Click Save.

          6. Ensure that you select SAML from the Enable Single Sign On drop-down.

          Optional: Auto-creation of user records

          When a user successfully authenticates via SAML, if a user record does not yet exist in the Sysdig platform database for their email address, one will be created at that time (default behavior). Some environments may not like this approach and may instead only want to permit logins for users whose records already exist (such as may have been already created via email invite or creation via the API).

          To disable the auto-creation of user records after SAML authentication, add the -n option to your command line when applying your settings. This will set createUserOnLogin to false .

          # ./saml_config.sh -s -n -m 'https://dev-824158.oktapreview.com/app/exkfpgqiskSoGZrjE0h7/sso/saml/metadata' -i okta
          {
            "authenticationSettings": {
              "id": 2,
              "version": 1,
              "createdOn": 1547539856000,
              "type": "saml",
              "scope": "SYSTEM",
              "settings": {
                "metadataUrl": "https://dev-824158.oktapreview.com/app/exkfpgqiskSoGZrjE0h7/sso/saml/metadata",
                "metadata": null,
                "validateSignature": true,
                "emailParameter": "email",
                "signedAssertion": true,
                "verifyDestination": true,
                "createUserOnLogin": false
              }
            }
          }
          

          User Experience

          As noted in the Basic Workflow, above, you can offer users three ways to log in with a SAML configuration:

          • They can begin at the Sysdig SaaS URL and click the SAML button.

            In the US East, Monitor: https://HOSTNAME/ or Secure: https://HOSTNAME/secure/.

            See SaaS Regions and IP Ranges for URLs for other regions.

            They will be prompted to enter a Company Name, so the Sysdig platform can redirect the browser to your IdP for authentication.

          • You can provide an alternative URL to avoid the user having to enter a company name, in the format:

            Sysdig Monitor: https://<HOSTNAME>/api/saml

            Sysdig Secure: https://<HOSTNAME>/api/saml/secureAuth

            This format is for the US East region. See SaaS Regions and IP Ranges for URLs for other regions.

          • You can configure an IdP-initiated login flow when configuring your IdP. The users then select the Sysdig application from your IDP’s app directory and do not browse directly to a Sysdig application URL at all.

          Users that complete their first successful SAML login to Sysdig Secure may receive the error message “User doesn’t have permission to login in Sysdig Secure”. This is because only members of the Secure Operations team are permitted access to Sysdig Secure, and newly-created logins are not in this team by default. Such a user should contact an Administrator for the Sysdig environment to be added to the Secure Operations team.

          Environments that wish to have all users access Secure by default could use this example script to frequently “sync” the team memberships.

          See also User and Team Administration for information on creating users.

          Caveats

          • SAML Assertion Encryption/Decryption is not currently supported.

          • SAML Single Logout is not supported. Therefore, users should take care to log out directly from Sysdig application(s).

          1 -

          Okta (SAML On-Prem)

          Review SAML (On-Prem) before you begin.

          Configure Sysdig Monitor and/or Sysdig Secure as a SAML application using Okta’s documentation for Setting Up a SAML Application in Okta. The notes below call out specific steps that require additional action.

          Sysdig-Specific Steps for Okta Configuration

          IDP-Initiated Login Flow

          If you don’t intend to configure IDP-initiated login flow, check the boxes for “Do not display application icon to users” and “Do not display application icon in the Okta Mobile app”.

          SSO, URI, and RelayState Values

          Enter the values shown in the table below, replacing HOSTNAME with the hostname through which your users access the Sysdig application(s) and PORT with the TCP port # (typically 443).

          To configure IDP-initiated login flow, replace CUSTOMER-ID-NUMBER with the number retrieved as described in Find Your Customer Number. (Normally the Customer ID will be 1 in on-prem installations.)

          Setting

          Value for Sysdig Monitor

          Value for Sysdig Secure

          Single sign on URL

          https://HOSTNAME:PORT/api/saml/auth

          https://HOSTNAME:PORT/api/saml/secureAuth

          Audience URI (SP Entity ID)

          https://HOSTNAME:PORT/api/saml/metadata

          https://HOSTNAME:PORT/api/saml/metadata

          Default RelayState

          (optional - only configure if you intend to use IDP-initiated login flow)

          #/&customer=CUSTOMER-ID-NUMBER

          #/&customer=CUSTOMER-ID-NUMBER

          You must include the port number in the IDP-side configuration, even though port 443 is the typical default for https:// URLs.

          Email and Name Values

          Instead of those shown in the Okta example, add these values:

          NameValue
          emailuser.email
          first nameuser.firstName
          last nameuser.lastName

          Note that the attributes are case sensitive, so use caution when entering them.

          Only email is required. However, including first/last name is recommended, since these values will now be included in the records created in the Sysdig platform’s database when new users successfully login via SAML for the first time.

          URL Metadata Value

          Copy the URL and paste in the Metadata entry on the SAML Configuration page in the SAML connection settings.

          Test Metadata (Optional)

          To ensure the metadata URL you copy at the end of the IDP configuration procedure is correct, you can test it by directly accessing it via your browser.

          When accessing the URL, your browser should immediately download an XML file that begins similarly to the example shown below. No entry of credentials or other security measures should be required to successfully download it. If this is not the case, revisit the IDP configuration steps.

          <?xml version= "1.0" ?> <EntityDescriptor xmlns= "urn:oasis:names:tc:SAML:2.0:metadata" entityID= "https://app.onelogin.com/saml/metadata/680358" > `<IDPSSODescriptor xmlns:ds=` `"http://www.w3.org/2000/09/xmldsig#" ` `protocolSupportEnumeration=` `"urn:oasis:names:tc:SAML:2.0:protocol"` `>names:tc:SAML:` `2.0` `:metadata` `" entityID="` ` https://app.onelogin.com/saml/metadata/ ` `680358` `">` ...

          2 -

          OneLogin (SAML On-Prem)

          Review SAML (On-Prem) before you begin.

          Configure Sysdig Monitor and/or Sysdig Secure as a SAML application using OneLogin’s article titled Use the OneLogin SAML Test Connector. The notes below call out specific steps that require additional action.

          Sysdig-Specific Steps for OneLogin Configuration

          Adding the SAML Test Connector

          At the step for “Adding the SAML Test Connector”, select SAML Test Connector (IdP w/ attr w/ sign response). If you don’t intend to configure IDP-initiated login flow, uncheck the slider so it will no longer be “Visible in portal”.

          Test Connector Configuration Page Settings

          At the “Test Connector Configuration Page”, enter the values shown in the table below. If you wish to configure IDP-initiated login flow, replace CUSTOMER-ID-NUMBER with the number retrieved as described in the Find Your Customer Number article.

          Field

          Value for Sysdig Monitor

          Value for Sysdig Secure

          RelayState

          (optional - only configure if you intend to use IDP-initiated login flow)

          #/&customer=CUSTOMER-ID-NUMBER

          #/&customer=CUSTOMER-ID-NUMBER

          Recipient

          https://HOSTNAME:PORT/api/saml/auth

          https://HOSTNAME:PORT/api/saml/secureAuth

          ACS (Consumer) URL Validator

          https://HOSTNAME:PORT

          https://HOSTNAME:PORT

          ACS (Consumer) URL

          https://HOSTNAME:PORT/api/saml/auth

          https://HOSTNAME:PORT/api/saml/secureAuth

          You must include the port number in the IDP-side configuration, even though port 443 is the typical default for https:// URLs.

          (Optional) If you want the user’s First Name and Last Name to be included in the records created in the Sysdig platform’s database when new users successfully login via SAML for the first time, click to the Parameters tab. Click Add parameter and create each of two New Fields, checking the box each time to Include in SAML assertion. Then click to Edit each field and select the Value shown from the drop-down menu before clicking Save.

          Field NameValue
          first nameFirst Name
          last nameLast Name

          Note that the Field Names are case sensitive , so be careful to enter them as all lowercase.

          The following shows an example of a correctly-configured field for First Name:

          Issuer URL

          Click to the SSO tab, copy the Issuer URL, and paste in the Metadata entry on the SAML Configuration page in the SAML connection settings.

          Test Metadata (Optional)

          To ensure the metadata URL you copy at the end of the IDP configuration procedure is correct, you can test it by directly accessing it via your browser.

          When accessing the URL, your browser should immediately download an XML file that begins similarly to the example shown below. No entry of credentials or other security measures should be required to successfully download it. If this is not the case, revisit the IDP configuration steps.

          <?xml version= "1.0" ?> <EntityDescriptor xmlns= "urn:oasis:names:tc:SAML:2.0:metadata" entityID= "https://app.onelogin.com/saml/metadata/680358" > `<IDPSSODescriptor xmlns:ds=` `"http://www.w3.org/2000/09/xmldsig#" ` `protocolSupportEnumeration=` `"urn:oasis:names:tc:SAML:2.0:protocol"` `>names:tc:SAML:` `2.0` `:metadata` `" entityID="` ` https://app.onelogin.com/saml/metadata/ ` `680358` `">` ...

          3 -

          Azure Active Directory (SAML On-Prem)

          This topic explains how to configure SAML Single Sign On (SSO) with Azure Active Directory (AD) and helps you configure Sysdig to allow users to access Sysdig application by using SSO.

          Prerequisites

          Administrator privileges on Sysdig and Azure.

          Configure the Sysdig Application in Azure AD

          1. Log in to the Azure AD portal.

          2. Select Azure Active Directory, then click Enterprise Applications.

            The Enterprise applications - All application screen is displayed.

          3. Click New Application.

          4. On the Add an Application screen, select Non-gallery application.

          5. Give your application a name, and click Add at the bottom of the page.

          6. On the menu, select Single sign-on.

          7. Choose SAML as the sign-on method.

          8. Edit the Basic SAML Configuration as follows:

            1. In the configuration page, click the edit icon.

            2. Specify the following:

              • Identifier (Entity ID): Uniquely identifies the Sysdig application. Azure AD sends the identifier to the Sysdig application as the audience parameter of the SAML token. Sysdig validates this as part of the SSO process.

                For example, the identifier for Sysdig Monitor for the EU region is https://eu1.app.sysdig.com.

                See SaaS Regions and IP Ranges for the complete list of entity IDs for different regions.

              • Reply URL: Specifies where Sysdig expects to receive the SAML token.

                For example, the identifier for Sysdig Monitor for the EU region is https://eu1.app.sysdig.com/api/saml/auth.

              • See SaaS Regions and IP Ranges for the complete list of reply URLs for different regions.

              • Relay State: Specifies to the application where to redirect the user after authentication is completed. Typically the value is a valid URL for Sysdig. If you are configuring SSO for SaaS, change the relay state to reflect the correct customer number associated with your Sysdig application. For on-prem installations, the customer number is always 1.

                The format is:

                #/&customer=1234
                
              • Sign on URL: It is the sign-in page for the Sysdig application that will perform the service provider-initiated SSO. Leave it blank if you want to perform identity-provider-initiated SSO.

              For more information on configuration parameters, see Configure SAML-based single sign-on to non-gallery applications.

          Sysdig-Specific Steps for Active Directory Configuration

          1. Under SAML Signing Certificate, copy the App Federation Metadata URL.

          2. Log in to your Sysdig instance as an admin.

            For on-prem deployments, log in as the super admin.

          3. Navigate to Settings > Authentication, and select SAML under Connection Settings.

          4. Enter the following:

            • Metadata: Enter the App Federation Metadata URL you copied.

            • Email Parameter: Set the value to emailaddress.

              Azure AD claims are:

              saml = AD
              givenname = user.givenname
              surname = user.surname
              emailaddress = user.mail
              name = user.userprincipalname
              Unique User Identifier = user.userprincipalname
              

              In the Sysdig application, you need to set the email to emailaddress which is what Azure AD sends to Sysdig in the SAML assertion. Alternatively, Azure AD can be modified to send another attribute.

          5. Click Save.

          6. Select SAML from the Enable Single Sign On drop-down.

          Create a User in Azure Active Directory Domain

          1. Log in to the Azure AD portal.

          2. Click Azure Active Directory, and note down the domain name.

          3. Select Azure Active Directory, then Users.

            The Users - All Users screen is displayed.

          4. Select New Users .

            You can either create a new user or invite an existing AD.

          5. Enter name, username, and other details, then click Create.

          6. In the Profile page, add the Email and Alternate Email parameters. The values can match

          Assign the User to the Sysdig Application

          1. Navigate to the Sysdig application.

          2. Click Users and Group, then click the Add user button.

          3. Select the Users and Groups checkbox, then choose the newly created user to add to the application.

          4. Click Select, then Assign at the bottom of the screen.

          Enable Authentication Settings in the Sysdig Instance

          Ensure that Flag to enable/disable create user on login is enabled. Typically this setting is enabled by default.

          If you are using both Sysdig Monitor and Secure, ensure that the user accounts are created on both the products. A user that is created only on one Sysdig application will not be able to log in to another by using SAML SSO.

          if you are on Sysdig Platform versions 2.4.1 or prior, contact Sysdig Support to help with user creation.

          (Optional) Configure Sysdig as a New Application

          If Azure Active Directory does not allow you to create Sysdig as a Non- Gallery application, perform the following:

          1. In Azure AD, click Enterprise Applications > New Application.

          2. Select Application you’re developing.

            You will be taken to the app registration page:

          3. Select New Registration:

          4. Provide a name for the application you are registering.

          5. Enter the redirect URI.

            For example, the redirect URI for Sysdig Monitor for the EU region is https://eu1.app.sysdig.com/api/saml/auth. See SaaS Regions and IP Ranges for the redirect URLs for other regions.

          6. Click Register to complete the registration.

          7. In the Overview tab click Add an Application ID URI:

          8. Click Add a scope.

          9. Add the application ID URI as follows:

            https://<your_sysdig_url>:443
            

            Replace <*your_sysdig_*url> with the URL appropriate to your application and region. See SaaS Regions and IP Ranges for more information.

          10. In the Overview tab, click Endpoints, and copy the Federation Metadata URL.

          11. Log in to Sysdig, navigate to SAML Authentication screen, and enter the Federation Metadata URL.

            You will still need to ensure that the user creation on the login option is enabled.

          12. Save the settings.

          4 -

          ADFS (SAML On-Prem)

          Review SAML (On-Prem) before you begin.

          These instructions assume you already have a working, Internet-accessible ADFS ( Active Directory Federation Service) server. Interoperability testing has been performed specifically with ADFS on Windows Server 2012 R2.

          Follow the instructions below to configure ADFS with the ADFS Management tool in the Windows Server Manager.

          For Service-Provider-Initiated Login Flow

          1. Right-click to Service > Edit Federation Service Properties. Note the hostname in the Federation Service Identifier, as this will be used in the metadata URL that you paste in the Metadata entry on the SAML Configuration page in the Sysdig authentication settings. Specifically, the metadata URL will be of the format https://HOSTNAME/FederationMetadata/2007-06/FederationMetadata.xml. Also, so that the Sysdig platform can access this URL directly, this host must resolve in DNS and have a valid (not self-signed) SSL/TLS certificate.

          2. Add a Relying Party Trust configuration for the Sysdig application.

            1. Right-click to Relying Party Trusts > Add Relying Party Trust and click Start to begin the wizard.

            2. In the Select Data Source step, click the button to Enter data about the relying party manually, then click Next

            3. Enter a Display name of your choosing (e.g. “Sysdig Monitor” or “Sysdig Secure”), then click Next

            4. Click Next to accept the default option to use AD FS profile

            5. Click Next to skip the selection of an optional token encryption certificate (Sysdig does not support this option)

            6. Check the box to Enable support for the SAML 2.0 Web SSO protocol, then enter one of the following values for Relying party SAML 2.0 SSO service URL:

              If configuring Sysdig Monitor in the US East, enter: https://<hostname>/api/saml/auth

              If configuring Sysdig Secure in the US East, enter: https://<hostname>/api/saml/secureAuth

              Replace <hostname> with the unique hostname associated with your on-prem deployment. For other regions, the format is https://<region>.<hostname>/api/saml/auth and https://<region>.<hostname>/api/saml/secureAuth.

              Then click Next.

            7. For the Relying party trust identifier, enter one of the following values:

              If configuring Sysdig Monitor in the US East, enter: https://<hostname>

              If configuring Sysdig Secure in the US East, enter: https://<hostname>/secure/

              Replace <hostname> with the unique hostname associated with your on-prem deployment. For other regions, the format is https://<region>.<hostname>/api/saml/auth and https://<region>.<hostname>/api/saml/secureAuth.

              Then click Add, then click Next

            8. Click Next to skip configuration of multi-factor authentication

            9. Choose a policy for whether users will be permitted to login to the Sysdig application. The default to Permit all users to access the relying party will typically be acceptable. Click Next.

            10. Review the summary and click Next to complete the configuration of the Relying Party Trust

            11. The next step will involve adding Claim Rules, so you can leave the box checked to Open the Edit Claim Rules dialog and click the Close button to be brought immediately into the Claim Rules editor

          3. Ensure that the SamlResponseSignature option matches the Sysdig authentication configuration.

            1. Use the Set-AdfsRelyingPartyTrust/Get-AdfsRelyingPartyTrust cmdlets via PowerShell to configure SamlResponseSignature .

              -SamlResponseSignature
              Specifies the response signatures that the relying party expects. The acceptable values for this parameter are:
              
              AssertionOnly
              MessageAndAssertion
              MessageOnly
              

              For more information, see Set-AdfsRelyingPartyTrust.

            2. Navigate to Settings > Authentication on the Sysdig app and check the Sysdig authentication setting maps to the SamlResponseSignature :

              For MessageAndAssertion, enable both the options.

          4. Next, use the Claim Rules to ensure that login data is sent as needed to the Sysdig platform. A user’s login to the Sysdig platform is based on an email address, and a default ADFS configuration would not send the email address as required. The following configuration ensures the correct field from Active Directory is delivered in the claim.

            1. If not already in the Claim Rules editor from the previous step, navigate to it by right-clicking on the Relying Party Trust that was just created and selecting Edit Claim Rules

            2. Click Add Rule. At the following screen, accept the default rule template to Send LDAP Attributes as Claims and click Next.

            3. Enter a name for the rule, select Active Directory as the Attribute store, then use the pull-down selectors to pick E-Mail Address as both the LDAP Attribute and Outgoing Claim Type, then similarly make pull-down selections for Given Name and Surname. Once these selections are made, click Finish.

            4. Now click Add Rule again, this time selecting the template for Transform an incoming claim

            5. Enter a name for the rule, then use the pull-downs to select an Incoming claim type of E-Mail Address, an Outgoing claim type of Name ID, and an Outgoing name ID format of Email, then click Finish.

            6. (Optional) If you want the user’s First Name and Last Name to be included in the records created in the Sysdig platform database when new users successfully login via SAML for the first time, additional Transform rules must also be created. Only the email-based username is strictly required and we already created a rule for this, so this step is optional.

              If you wish to do this, click Add Rule and once again select the template for Transform an incoming claim. Enter a name for the rule, then use the pull-down to select an Incoming claim type of Given Name, and for the Outgoing claim type, directly type first name into the field. After clicking Finish, click Add Rule and create a similar rule to transform the Incoming claim type of Surname to the Outgoing claim type of last name.

            7. Having clicked Finish after creating your last rule, you will see all rules now in the editor. Click Ok, and your ADFS configuration for your Sysdig application is complete.

          For IdP-Initiated Login Flow (Optional)

          (Optional) The steps above represent a Service-Provider-Initiated SAML configuration. If you would prefer an IdP-initiated SAML configuration, this is also possible with ADFS, but requires the additional steps described below.

          1. The Sysdig platform requires a specific setting of RelayState in order to accept IdP-initiated login flows. On the ADFS versions tested, we’ve found this use of RelayState is disabled by default, and a Microsoft article describes the topic in detail. To enable it, as described in a Microsoft forum thread, on your ADFS host, edit %systemroot%\ADFS\Microsoft.IdentityServer.Servicehost.exe.config and add <useRelayStateForIdpInitiatedSignOn enabled="true" /> to the <microsoft.identityserver.web> section. Once the modification is saved, restart ADFS services for the change to take effect.

          2. You will need to retrieve your Sysdig customer number as described in the Find Your Customer Number article.

          3. You will then need to generate an IdP-initiated login URL.

            In addition to having the correct settings, it must be properly URL encoded. To ease this configuration, use this ADFS RelayState Generator tool. When launched, enter the values below, then hit the Generate URL button.

            • For the IDP URL String, enter https://YOUR_ADFS_SERVER/adfs/ls/idpinitiatedsignon.aspx

            • For the Relying Party Identifier, enter one of the following values if you are in the US East region:

              • If configuring Sysdig Monitor, enter https://<hostname>.

              • If configuring Sysdig Secure, enter https://<hostname>/secure/

              Replace hostname> with the unique hostname associated with your on-prem deployment.

              For other regions, the format is https://<region>.<hostname> for Sysdig Monitor and https://<region>.<hostname>/secure/ for Sysdig Secure. Replace <region> with the region where your Sysidig application is hosted. For example, for Sysdig Monitor in the EU, you use https://eu1.<hostname>.

              See SaaS Regions and IP Ranges for more information on regions.

            • For the Relay State/Target App, enter #/&customer=CUSTOMER-ID-NUMBER, substituting the CUSTOMER-ID-NUMBER you retrieved in the previous step

              This Results URL will be used in the metadata URL that you paste in the Metadata entry in the SAML connection settings .

          4. Use the Results URL from the tool to test your IdP-initiated login. Note that per this Microsoft forum thread, it is apparently not possible to configure ADFS to use such a URL when your users select the application from the pull-down menu at https://YOUR_ADFS_SERVER/adfs/ls/idpinitiatedsignon.aspx. However, you may embed the URL into a custom portal or bookmarks list.

          5. Now you can test login using an Active Directory user that has an Email address configured.

          Test Metadata (Optional)

          To ensure the metadata URL you copy at the end of the IDP configuration procedure is correct, you can test it by directly accessing it via your browser.

          When accessing the URL, your browser should immediately download an XML file that begins similarly to the example shown below. No entry of credentials or other security measures should be required to successfully download it. If this is not the case, revisit the IDP configuration steps.

          <?xml version= "1.0" ?> <EntityDescriptor xmlns= "urn:oasis:names:tc:SAML:2.0:metadata" entityID= "https://app.onelogin.com/saml/metadata/680358" > `<IDPSSODescriptor xmlns:ds=` `"http://www.w3.org/2000/09/xmldsig#" ` `protocolSupportEnumeration=` `"urn:oasis:names:tc:SAML:2.0:protocol"` `>names:tc:SAML:` `2.0` `:metadata` `" entityID="` ` https://app.onelogin.com/saml/metadata/ ` `680358` `">` ...