Authentication and authorization overview

For reference, see Access Gateway Functional Components Overview for a complete picture of how the Access Gateway components operate together.

Authentication Component

Access Gateway AuthenticationAuthentication is distinct from authorization, which is the process of giving individuals access to system objects based on their identity. Authentication merely ensures that the individual is who he or she claims to be, but says nothing about the access rights of the individual. Authentication methods and protocols include direct auth, delegated auth, SAML, SWA, WS-Fed, and OpenID Connect. component contains the 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 a chiclet, sending a SAMLResponse to the configured SP. A session is established with the SP, and the end user is authenticated. functionality, identity provider capabilities, handshake logic, and more.

SAML Service Provider

Access Gateway supports user flows that originate from an Identity Provider by acting as a service provider via SAML protocol. This functionality enables applications that lack SAML components to authenticate with IDaaS solutions without custom development.

Identity Provider

Access Gateway also provides identity provider capabilities through 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. certificate authentication. Additionally, there are alternate authentication methods available.

Handshake and Authorization Session

Temp auth cookie Populate session attributes SAML attributes Static values External data source lookups

Authorization Component

The Authorization component handles sessions and policies for the Access Gateway appliance.

Handshake from Authentication

Once a user is authenticated, Access Gateway can upgrade an authorization cookie to a session cookie.

Sessions

• Per application

• Idle, max

• Finger printing

• Session cookie

Policy

• Authorized users

• Unauthorized users

• Rule-based

• Certificates