15- Create a SAML Integration using AIW Flashcards
Create a SAML integration using AIW - Task 1
Note: Ensure that you add Okta to your browser’s allow list for 3rd-party cookies to prevent errors in your integrations. See Allow Third-Party Cookies for detailed instructions.
Task 1: Launch the Wizard
- 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.
- In the Admin Console, go to Applications > Applications.
- Click Add Application.
- Click Create New App.
- To create a SAML integration, select Web as the Platform and SAML 2.0 for the Sign on method.
- Click Create.
Create a SAML integration using AIW - Task 2
- Application name — Specify a name for your integration. 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.
Create a SAML integration using AIW- Task 3
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.
Create a SAML integration using AIW- Task 4
Configure feedback
- 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 who 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:
Configure an app sign-on policy (optional)
Assign applications to users
Assign an app integration to a group
Submit an app integration to the OIN
https://help.okta.com/en/prod/Content/Topics/Apps/Apps_App_Integration_Wizard_SAML.htm#Task
Create an OIDC app integration using AIW- Task 1
Task 1: Launch the Wizard
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.
In the Admin Console, go to Applications >Applications.
Click Add Application.
Click Create New App.
To create an OIDC app integration, select either Web, Native App, or Single Page App (SPA) as the Platform and OpenID Connect for the Sign on method.
Click Create.
Create an OIDC app integration using AIW- Task 2
Task 2: Configure initial settings
The Open ID Connect App Integration Wizard has two sections:
In General Settings:
A default name is automatically provided for you, based on the platform you selected. If there is already an app integration in your Okta org with that default name, then a number is also added to the app name field to differentiate between the two app integrations.
Application name — Specify a name for your integration. 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.
Create an OIDC app integration using AIW- Task 2
In Configure OpenID Connect:
- Login Redirect URIs —
The Login Redirect URI is where Okta sends the authentication response and ID token for the user’s sign-in request. The URIs must be absolute URIs. You can specify more than one. As your OIDC application must explicitly request which redirect_uri is used, the order doesn’t matter. However, if your OIDC application sends requests a URI that isn’t registered with your Okta app integration, your users are sent to an error page when they try to sign on.
Optional. Logout Redirect URIs — After your application contacts Okta to close the user session, Okta then redirects the user to one of these URIs. The URIs must be absolute URIs. You can specify more than one.
Click Save. This creates the integration and opens the settings page to configure additional options.
Create an OIDC app integration using AIW- Task 3
Task 3: Configure OIDC settings
The options in the General Settings tab are similar for all OIDC integration types. Click Edit to change any of the listed options.
Web apps
- Select from among the different grant type options.
- Enter one or more Login redirect URIs where Okta will send OAuth responses.
- Enter one or more Logout redirect URIs where Okta will redirect the browser after logging out from the relying-party and terminating its end-user session.
- Select a Login initiated by setting to specify if the sign-in process is initiated directly by the application in the background, or if either the application or Okta can initiate the sign-in request.
If you select App Only, the application is started in the background, without an Okta tile appearing.
If you select Either Okta or App, your integration uses an Okta tile:
Select the appropriate Application visibility option.
Select the appropriate Login flow option. If you choose Send ID Token directly to app (Okta Simplified), you’re also able to choose OIDC scopes for the flow.
An App Embed Link section is displayed at the bottom of the settings page, showing the URL that you can use to sign in to the OIDC client from outside of Okta.
- You can use the API endpoint openid-configuration to configure Okta interactions programmatically. When a web application contains the implicit value for grant_types_supported, admins can publish integrations with the Login Initiated By feature. For more information about OIDC clients and the API, see the OpenID Connect API.
- Enter or change the Initiate login URI used to initiate the sign-in request.
- Click Save to commit your changes.
- If required, you can generate a new client secret. In the Client Credentials section, click Edit then click Generate New Client Secret.
Create an OIDC app integration using AIW- Task 3
Task 3: Configure optional settings
Native apps
- Select from among the different grant type options.
- Enter one or more Login redirect URIs where Okta will send OAuth responses.
- Enter one or more Logout redirect URIs where Okta will redirect the browser after logging out from the relying-party and terminating its end-user session.
- Click Save to commit your General Settings changes.
- In the Client Credentials section, you can select a Client authentication type:
- Use PKCE (for public clients) — Recommended for native applications. By requiring a Proof Key for Code Exchange (PKCE), this option ensures that only the client that requested the access token can redeem it.
- Use Client Authentication — This option is not recommended for distributed native applications. A client secret is embedded in the client and sent with requests to prove the client’s identity. - Click Save to commit your changes.
https: //help.okta.com/en/prod/Content/Topics/Apps/Apps_App_Integration_Wizard_OIDC.htm
Create an OIDC app integration using AIW- Task 3
Single page apps
- Select from among the different grant type options.
- Enter one or more Login redirect URIs where Okta will send OAuth responses.
- Enter one or more Logout redirect URIs where Okta will redirect the browser after logging out from the relying-party and terminating its end-user session.
- Select a Login initiated by setting to specify if the sign-in process is initiated directly by the application in the background, or if either the application or Okta can initiate the sign-in request.
- If you select App Only, the application is started in the background, without an Okta tile appearing.
- If you select Either Okta or App, your integration uses an Okta tile:
-Select the appropriate Application visibility option.
- Select the appropriate Login flow option. If you choose Send ID Token directly to app (Okta Simplified), you’re also able to choose OIDC scopes for the flow.
- An App Embed Link section is displayed, showing the URL that you can use to sign in to the OIDC client from outside of Okta.
5. You can use the API endpoint openid-configuration to configure Okta interactions programmatically. When a web application contains the implicit value for grant_types_supported, admins can publish apps with the Login Initiated By feature. For more information about OIDC clients and the API, see the OpenID Connect API.
6. Enter or change the Initiate login URI used to initiate the sign-in request.
7. Click Save to commit your changes.
Create an OIDC app integration using AIW- Task 4
Consent
This is an Early Access feature. To enable it, contact Okta Support.
If you have enabled User Consent for OAuth 2.0 Flows in API Access Management, then the following section appears in the General Settings tab for an OIDC integration.
If you want prompt the user with a pop-up window to approve the integration’s access to specified resources, check the Require consent box. Additionally, you can set up the consent for an OIDC scope in your custom authorization, as described in the Create Scopes section of API Access Management.
Set the Groups Claim Filter
- Go to the Sign On tab and scroll down to the OpenID Connect ID Token section.
- Select the Groups claim type. You can select either a Filter for existing group claims, or chose an Expression to create a custom filter on a different group claim. If the value you specify in Groups claim filter matches more than 100 groups, an error occurs when the API tries to create ID tokens.
For more information about Group claims for Single Sign-On, see Customize tokens returned from Okta.
Next steps
If your integration does not behave as expected, contact Okta support at support@okta.com for assistance.
Assign applications to users
Assign an app integration to a group
Submit an app integration to the OIN
What is SCIM?
SCIM, or the System for Cross-domain Identity Management specification, is an open standard designed to manage user identity information. SCIM provides a defined schema for representing users and groups, and a RESTful API to run CRUD operations on those user and group resources.
What is the goal of SCIM?
The goal of SCIM is to securely automate the exchange of user identity data between your company’s cloud applications and any service providers, such as enterprise SaaS applications.
What are the benefits of Life Cycle Management
Okta Lifecycle Management is a platform solution to provision and manage user accounts in cloud-based applications. Okta serves as a universal directory for identity-related information, giving the following benefits:
- IT departments can manage the user provisioning lifecycle through a single system.
- New employees are automatically provisioned with a user account for their applications.
- Employee accounts can be created either directly from Okta accounts, or shared from external systems like HR applications or Active Directory.
- Any profile updates - like department changes - populate automatically.
- Inactive employees are automatically deactivated from their applications.
How does SCIM work?
Provisioning consists of a set of actions between a service provider - like Okta - and the cloud-based integration (the SCIM client). Using REST style architecture and JSON objects, the SCIM protocol communicates data about users or groups. As an application developer, you define the use cases needed and then build the corresponding SCIM actions into your integration.
- By implementing support for the SCIM standard, an integration in the Okta Integration Network can be notified when a user is created, updated, or removed from their application in Okta.
- The provisioning actions performed by an integration are described using the database operation acronym “CRUD”: Create, Read, Update, and Delete. The four CRUD operations are the building blocks that combine to solve your end-to-end use cases:
Create a SCIM integration using AIW - Task 2
Task 2: Add SCIM provisioning
After your integration is created, click the General tab.
- Click Edit
- In the Provisioning section, select SCIM and click Save
Create SCIIM Integration Using AIW - Task 3
Task 3: Choose provisioning options
- From the integration’s settings page, choose the Provisioning tab. The SCIM connection settings appear under Settings > Integration.
- Click Edit.
- Specify the SCIM connector base URL and the field name of the unique identifier for your users on your SCIM server.
- Under Supported provisioning actions, choose the provisioning actions supported by your SCIM server
