Create a SAML integration using AIW


SAML integrations use Federated Authentication standards to give end users one-click access to your SAML app. The AIW generates the XML needed for the SAML request.

Before you begin

Task 1: Launch the Wizard

  1. Verify that you are using the Admin Console. If you are using the Developer Console, you need to switch over to the Admin Console. If you see < > Developer Console in the top left corner of your console, click it, then click Classic UI to switch.
  2. In the Admin Console, go to Applications > Applications.
  3. Click Add Application.
  4. Click Create New App.
  5. To create a SAML integration, select Web as the Platform and SAML 2.0 for the Sign on method.
  6. Click Create.

Task 2: Configure general settings

  • App name — Specify a name identifier for your integration.
    Info

    Note

    The name can only consist of UTF-8, 3 byte characters

  • Optional. App logo — Add a logo to accompany your integration in the Okta org. The logo file must be PNG, JPG, or GIF format and be smaller than 1 MB in size. For best results, use a PNG image with a transparent background, a landscape orientation, and use a minimum resolution of 420 x 120 pixels to prevent upscaling.
  • App visibility — Choose whether to hide your integration from your end-users' homepage. Choose whether to hide your integration from the Okta Mobile Apps Store on your end-users devices.

Task 3: Configure SAML settings

A SAML 2.0 configuration requires a combination of information from both your org and the target app. For help completing each field, use your app-specific documentation and the Okta tool tips.

  • Single sign on URL — The location where the SAML assertion is sent with a POST operation. This URL is required and serves as the default ACS URL value for the Service Provider (SP). This URL is always used for IdP-initiated sign-on requests.
    • Use this for Recipient URL and Destination URL — Select this check box if you want the recipient and destination URL to be the same.
      • Recipient URL — (Appears if the previous check box is not selected.) The location where the application may present the SAML assertion. This is usually the Single Sign-On (SSO) URL.
      • Destination URL — (Appears if the previous check box is not selected.) The location where the SAML Response is intended to be sent inside the SAML assertion. This should be the same location as the Single sign on URL unless your application explicitly defines a specific value.
    • Allow this app to request other SSO URLs — For use in SP-initiated sign-in flows. Select this option to configure multiple ACS URLs to support applications capable of choosing where the SAML Response is sent. Specify an index or URL to uniquely identify each ACS URL endpoint. If an AuthnRequest message does not specify an index or URL, the SAML Response is sent to the default ACS URL specified in the Single sign on URL field.
      • Requestable SSO URLs — (Appears if the previous check box is selected.) Enter the SSO URLs for any other nodes.
  • Audience URI (SP Entity ID) — The intended audience of the SAML assertion. This is usually the Entity ID of your application.
  • Default RelayState — The page where users land after a successful sign-in using SAML into the SP. This should be a valid URL. Consult the SP documentation to get this information.
  • Name ID format — The username format you are sending in the SAML Response. Consult the SP documentation to determine which format to use, but use the default (Unspecified) if the application does not explicitly specify a format.
  • Application username — The default value to use for the username with the application.
  • Info

    Important

    To maintain security, do not use fields that can be edited by end users.

  • Attribute Statements (Optional) — When you create a new SAML integration, or modify an existing one, you can define custom attribute statements. These statements are inserted into the SAML assertions shared with your app.
  • Group Attribute Statements (Optional) — If your Okta org uses groups to categorize users, you can add group attribute statements to the SAML assertion shared with your app.
  • Info

    Note

    The Dynamic SAML feature does not change the way attribute statements are entered or processed by the Okta Expression Language. This feature enables SAML attribute statements to be processed by apps in the Okta Integration Network; previously the attribute statements were only available for apps created using the App Integration Wizard.

  • Click < > Preview the SAML Assertion to view the XML generated from the Configure SAML section of the SAML App Wizard.

Task 4: Configure feedback

If you are an Okta customer adding an integration that is intended for internal use only:

  • Select I'm an Okta customer adding an internal app
  • Click the check box for This is an internal app that we have created or, if your app requires additional SAML configuration instructions to work with Okta, click the check box for It's required to contact the vendor to enable SAML. Fill in the provided fields to help the Okta support team understand your SAML configuration.
  • Click Finish. Your integration is created in your Okta org.
  • The Settings page for your integration appears, where you can modify any of the parameters and assign your integration to users.

If you are an ISV that wants to add your integration to the Okta Integration Network (OIN):

  • Select I'm a software vendor. I'd like to integrate my app with Okta.
  • Click Finish. Your integration is created in your Okta org.
  • The Settings page for your integration appears, where you can modify any of the parameters and assign your integration to users.
  • After you are satisfied that all settings are correct and you have completed your preliminary testing, click Submit your app for review. This opens the OIN manager site and begins the OIN submission process.

Next steps