About Okta as IdP

One of the first tasks required after deploying Access Gateway is to configure an Okta orgThe Okta container that represents a real-world organization. as an identify provider. Once configured Access Gateway interacts with the configured Okta org to provide a variety of services, the most common being authentication.
Access Gateway authenticates with an Okta org in one of two ways:


Okta Org initiated flow

In an Okta initiated flow, the user accesses an Okta tenant, logging in using a browser or hand held device(1). Okta authenticates(2) the user and directs them to their set of defined applications. When the user selects an appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in. tile representing an application managed by Access Gateway the Okta org provided credential information, typically in the form of a SAMLAn acronym for Security Assertion Markup Language, SAML is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). The SAML standard addresses issues unique to the single sign-on (SSO) solution, and defines three roles: the end user, the IdP, and the SP. Here's how SAML works through Okta: SP-initiated flow: the end user requests (principally through a browser) a service from the SP. The SP requests and obtains an identity assertion from the IdP (in this case, Okta). On the basis of this assertion, the SP can decide whether or not to authorize or authenticate the service for the end user. IdP-initiated flow: with Okta as the IdP, an end user goes to the Okta browser and clicks on an app, sending a SAMLResponse to the configured SP. A session is established with the SP, and the end user is authenticated. assertion to Access Gateway which then directs the request to the clientEssentially, a client is anything that talks to the Okta service. Within the traditional client-server model, Okta is the server. The client might be an agent, an Okta mobile app, or a browser plugin. application(4).


Direct to Access Gateway initiated flow

In the Direct to Access Gateway initiated flow, a user accesses an application proxied by Access Gateway directly (1). Access Gateway then asks Okta for authentication (2). The Okta org then authenticates(3) and returns back to Access Gateway the appropriate assertion(4). Access Gateway then forwards the request to the underlying protected application resource(5).