SAML app integrations
Security Assertion Markup Language (SAML) is an XML-based protocol used for Single Sign-On (SSO) and exchanging authentication and authorization data between applications. Within the SAML workflow, Okta can act as both the Identity Provider (IdP) or as the Service Provider (SP), depending on your use case.
SAML is the protocol most organizations use for SSO and enterprise security. The primary appeal for SAML comes from the fact that SAML helps reduce the attack surface for organizations and improves the customer's sign-in experience.
When a user signs in to an application using SAML, the IdP sends a SAML assertion to their browser that is passed to the SP. In many circumstances, the IdP verifies the user (with Multifactor Authentication (MFA), for example) before issuing the SAML assertion.
The SAML assertion is an XML file with three statement types: authentication, attribution, and authorization. The authentication statement covers when and how the subject is authenticated. The attribution statement provides details about the user, such as group membership or their role within a hierarchy. Finally, the authorization statement tells the SP which level of authorization the user has across different resources. This way, SAML goes beyond mere authentication and authorizes the user for multiple privileges, protecting your application in the process.
Admins can browse the OIN catalog and set the filter to search for app integrations with SAML as a functionality. When added to an org and assigned to an end user by an admin, the SAML-enabled app integration appears as a new icon on the End-User Dashboard.
Okta as Identity Provider
Okta can integrate with SAML 2.0 applications as an IdP that provides SSO to external applications. Okta also supports MFA prompts to improve your application security.
When users request access to an external application registered with Okta, they're redirected to Okta. As the IdP, Okta then delivers a SAML assertion to the browser. The browser uses the assertion to authenticate the user to the SP.
- The user attempts to access applications protected by Okta using SAML for SSO.
- Client applications act as SAML Service Providers and delegate the user authentication to Okta. The client applications send a SAML assertion to Okta to establish the user session.
- Okta acts as the SAML IdP and uses SSO and MFA to authenticate the user.
- Okta returns an assertion to the client applications through the end user's browser.
- The client applications validate the returned assertion and allow the user access to the client application.
Okta as Service Provider
Okta can also serve as the SP that consumes authentication from other SSO solutions like IBM Tivoli Access Manager, Oracle Access Manager, or CA SiteMinder, for example.
In this scenario, if a user tries to sign in to Okta, they're redirected to an external IdP for authentication. After the user has successfully authenticated, the external IdP returns the SAML assertion, which is then passed through the user’s browser to access the Okta services.
- The user opens Okta in a browser to sign in to their cloud or on-premises app integrations.
- Okta acts as the SP and delegates the user authentication to the external IdP.
- The external IdP authenticates the user.
- The IdP sends a SAML assertion back to Okta.
- Okta validates the SAML assertion from the external IdP and, if necessary, enforces MFA. Users can be created in Okta using Just-In-Time provisioning if required.
Users, client applications, and external IdPs can all be on your intranet and behind a firewall, provided that the end user can reach Okta through the internet.