Securing applications is the core of Access Gateway.
Applications are deployed using an architecture similar to that shown in the Access Gateway Application Architecture diagram.
In general, Access Gateway:
- Acts as a reverse-proxy
- Integrates with on-premises application using legacy patterns.
- Has individual 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. contracts and authorization policies for each on-premises application.
- Applications have their own SAML encryption, assertion attributes, session timeouts, MFA policies, and URL authorization.
Each application protected by Access Gateway is configured individually according to its specific needs and requirements.
When creating an application configuration in Access Gateway, there are various application templates available to speed the configuration process. Each application template is geared towards a specific set of application requirements. The Access Gateway Supported Applications page includes a list of all supported application types. The Supported Technologies page contains a list of all currently supported application versions and similar information.
There are many sample applications, in this guide we will integrate an example header application.
The header 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. helps you familiarize yourself with how Access Gateway works as well as providing testing endpoint in case you need to troubleshoot application integration.
- Access Gateway is installed and configured for use.
See Manage Access Gateway deployment.
- Access Gateway has been configured to use your Okta tenant as IDPAn acronym for Identity Provider. It is a service that manages end user accounts analogous to user directories such as LDAP and Active Directory, and can send SAML responses to SPs to authenticate end users. Within this scenario, the IdP is Okta..
See Configure your Okta tenant as Identity Provider for more information about configuring your Okta tenant as an IDP.
- You have administrator rights on your Okta tenant and can assign applications to users, and create groupsGroups allow you to organize your end users and the apps they can access. Assigning apps to large sets of end users is made easier with groups..
Appropriate DNS entries exist for the application.
A best practice for testing a header application is to add header.<yourdomain> to the /etc/hosts for testing purposes. On Windows this file can be found in c:\windows\system32\drivers\etc\hosts.
This entry should point to the same IP address as uses for Access Gateway. For example:
. . .
10.0.0.1 adminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page.
. . .
Navigate to your Access Gateway instance and sign in as admin.
Access Gateway creates a default self-signed certificate. For non-production deployments, this will be appropriate. Proceed past any security exceptions raised by your browser. For production deployments, a valid certificate can be installed and these exceptions will not be needed.
- Click the Applications tab
- Click + Add to add a new application.
Select the Header Based option from the left column menu, and click Create.
The New Protected Application wizard will start and display the Essentials pane for the application being added.
In the Essentials pane specify the following:
Field Value Label A name for the application.
For example: Example Header Application
Public DomainA domain is an attribute of an Okta organization. Okta uses a fully-qualified domain name, meaning it always includes the top-level domain (.com, .eu, etc.), but does not include the protocol (https). A fully qualified host name such as header.<your domain>.
For testing, add header.<yourdomain> to /etc/hosts.
Protected Web Resource The URL of the protected resources.
For testing enter http://header.service.spgw.
Specifying a protected web resource of header.server.spgw tells Access Gateway to execute the header test suite when executed.
Group Enter the group containing the users who should have access to the application.
For testing this is typically the Everyone group.
Description [optional] An appropriate description for your application.
Review the Settings tab then click Done.
For more information on the application setting options, see Application Settings.
Return to the Access Gateway Admin Console.
Select the new application and click the pencil icon.
In the Attributes section, click the +.
Scroll down to the Add new Session Attribute window.
In the Name field, enter manager, and select the manager attribute type in the Value field.
In the Value menu, type in the name of the attribute you want to add, and then click the new attribute in the dropdown menu.
- Click Done.
- Confirm that the Header App is displayed as Active in the Protected Applications list.
- In the row containing the application click the Goto > SPAn acronym for service provider. Generally, an SP is a company, usually providing organizations with communications, storage, processing, and a host of other services. Within Okta, it is any website that accepts SAML responses as a way of signing in users, and has the ability to redirect a user to an IdP (e.g., Okta) to begin the authentication process. Initiated.
- In the application page, review and verify that the Header App sent to Okta matches your profile information.
For a complete list of all applications and their associated integrations details see Integrating Applications with Access GatewayTop