Classic portal: Deploy Conditional Access App Control for catalog apps with non-Microsoft IdP

Access and session controls in Microsoft Defender for Cloud Apps work with applications from the Cloud app catalog and with custom applications.

Defender for Cloud Apps preonboards the following apps to work out-of-the-box:

If you're interested in a specific app being preonboarded, send us details about the app. Be sure to send the use case you're interested in for onboarding it.

Prerequisites

• Your organization must have the following licenses to use Conditional Access App Control:

  • The license required by your identity provider (IdP) solution
  • Microsoft Defender for Cloud Apps

• Apps must be configured with single sign-on

• Apps must use one of the following authentication protocols:

  IdP	Protocols
  Microsoft Entra ID	SAML 2.0 or OpenID Connect
  Other	SAML 2.0

To deploy catalog apps

Follow these steps to configure catalog apps to be controlled by Microsoft Defender for Cloud Apps Conditional Access App Control.

Step 1: Configure your IdP to work with Defender for Cloud Apps

Step 2: Sign in to each app using a user scoped to the policy

Step 3: Verify the apps are configured to use access and session controls

Step 4: Enable the app for use in your organization

Step 5: Test the deployment

Step 1: Configure your IdP to work with Defender for Cloud Apps

Configure integration with other IdP solutions

Use the following steps to route app sessions from other IdP solutions to Defender for Cloud Apps. For Microsoft Entra ID, see Configure integration with Microsoft Entra ID.

1. In Defender for Cloud Apps, browse to Investigate > Connected apps > Conditional Access App Control apps.

2. Select + Add, and in the pop-up, select the app you want to deploy, and then select Start Wizard.

3. On the APP INFORMATION page, fill out the form using the information from your app's single sign-on configuration page, and then select Next.

   • If your IdP provides a single sign-on metadata file for the selected app, select Upload metadata file from the app and upload the metadata file.
   • Or, select Fill in data manually and provide the following information:
     • Assertion consumer service URL
     • If your app provides a SAML certificate, select Use <app_name> SAML certificate and upload the certificate file.

   

4. On the IDENTITY PROVIDER page, use the provided steps to set up a new application in your IdP's portal, and then select Next.

   1. Go to your IdP's portal and create a new custom SAML app.
   2. Copy the single sign-on configuration of the existing <app_name> app to the new custom app.
   3. Assign users to the new custom app.
   4. Copy the apps single sign-on configuration information. You'll need it in the next step.

   

   Note

   These steps may differ slightly depending on your identity provider. This step is recommended for the following reasons:

   • Some identity providers do not allow you to change the SAML attributes or URL properties of a gallery app
   • Configuring a custom app enables you to test this application with access and session controls without changing the existing behavior for your organization.

5. On the next page, fill out the form using the information from your app's single sign-on configuration page, and then select Next.

   • If your IdP provides a single sign-on metadata file for the selected app, select Upload metadata file from the app and upload the metadata file.
   • Or, select Fill in data manually and provide the following information:
     • Assertion consumer service URL
     • If your app provides a SAML certificate, select Use <app_name> SAML certificate and upload the certificate file.

   

6. On the next page, copy the following information, and then select Next. You'll need the information in the next step.

   • Single sign-on URL
   • Attributes and values

   

7. In your IdP's portal, do the following:

   Note

   The settings are commonly found in IdP portal's custom app settings page

   1. In the single sign-on URL field, enter the single sign-on URL you made a note of earlier.

      Note

      Some providers may refer to the single sign-on URL as the Reply URL.

   2. Add the attributes and values you made a note of earlier to the app's properties.

      Note

      • Some providers may refer to them as User attributes or Claims.
      • When creating a new SAML app, the Okta Identity Provider limits attributes to 1024 characters. To mitigate this limitation, first create the app without the relevant attributes. After creating the app, edit it, and then add the relevant attributes.
   3. Verify that the name identifier is in the email address format.
   4. Save your settings.

8. On the APP CHANGES page, do the following, and then select Next. You'll need the information in the next step.

   • Copy the Single sign-on URL
   • Download the Defender for Cloud Apps SAML certificate

   

9. In your app's portal, on the single sign-on settings, do the following:

   1. [Recommended] Create a backup of your current settings.
   2. Replace the Identity Provider Login URL field value with the Defender for Cloud Apps SAML single sign-on URL you noted earlier.
   3. Upload the Defender for Cloud Apps SAML certificate you downloaded earlier.
   4. Select Save.

   Note

   • After saving your settings, all associated login requests to this app will be routed through Conditional Access App Control.
   • The Defender for Cloud Apps SAML certificate is valid for one year. After it expires, a new certificate will need to be generated.

Step 2: Sign in to each app using a user scoped to the policy

After you've created the policy, sign in to each app configured in that policy. Make sure you sign in using a user configured in the policy.

Defender for Cloud Apps will sync your policy details to its servers for each new app you sign in to. This may take up to one minute.

Step 3: Verify the apps are configured to use access and session controls

The preceding instructions helped you create a built-in Defender for Cloud Apps policy for catalog apps directly in Microsoft Entra ID. In this step, verify that the access and session controls are configured for these apps.

1. In the Defender for Cloud Apps portal, select the settings cog , and then select Conditional Access App Control.

2. In the Conditional Access App Control apps table, look at the Available controls column and verify that both Access control or Microsoft Entra Conditional Access, and Session control appear for your apps.

   Note

   If session control doesn't appear for an app, it's not yet available for that specific app. You can either add it immediately as a custom app, or you can open a request to add it as a catalog app by clicking Request session control.

   

Step 4: Enable the app for use in your organization

Once you're ready to enable the app for use in your organization's production environment, do the following steps.

1. In Defender for Cloud Apps, select the settings cog , and then select Conditional Access App Control.

2. In the list of apps, on the row in which the app you're deploying appears, choose the three dots at the end of the row, and then choose Edit app.

3. Select Use with Conditional Access App Control and then select Save.

   

Step 5: Test the deployment

1. First sign out of any existing sessions. Then, try to sign in to each app that was successfully deployed. Sign in using a user that matches the policy configured in Microsoft Entra ID, or for a SAML app configured with your identity provider.

2. In the Defender for Cloud Apps portal, under Investigate, select Activity log, and make sure the login activities are captured for each app.

3. You can filter by clicking on Advanced, and then filtering using Source equals Access control.

   

4. It's recommended that you sign into mobile and desktop apps from managed and unmanaged devices. This is to make sure that the activities are properly captured in the activity log.
   To verify that the activity is properly captured, select a single sign-on login activity so that it opens the activity drawer. Make sure the User agent tag properly reflects whether the device is a native client (meaning either a mobile or desktop app) or the device is a managed device (compliant, domain joined, or valid client certificate).

Next steps

If you run into any problems, we're here to help. To get assistance or support for your product issue, please open a support ticket.