You can configure the Okta browser plugin to behave on your custom end user portal exactly as it behaves in the Okta end user dashboard. When configured, the plugin does the following:
- The plugin informs the custom portal that it (the plugin) is present. You can configure your custom portal to detect when the plugin is not installed, and then display a banner prompting end usersEnd users are people in your org without administrative control. They can authenticate into apps from the icons on their My Applications home page, but they are provisioned, deprovisioned, assigned, and managed by admins. to install the plugin.
- The plugin makes the following API calls to the Okta server to update its state:
Retrieves information about the list of sites on your custom end user portal (useful for SSOAn acronym for single sign-on. In a SSO system, a user logs in once to the system and can access multiple systems without being prompted to sign in for each one. Okta is a cloud-based SSO platform that allows users to enter one name and password to access multiple applications. Users can access all of their web applications, both behind the firewall and in the cloud, with a single sign in. Okta provides a seamless experience across PCs, laptops, tablets, and smartphones. scenarios).
Retrieves information about the location of tabs and apps on the portal in order to construct the Your Apps menu that displays when end users click the blue plugin icon. Screenshot
Retrieves information about the currently logged-in user such as the plugin settings that are enabled.
Retrieves information useful for adding apps on-the-fly.
This procedure has two parts:
- From the Okta 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. console, go to Security > API.
- Click the Trusted Origins tab.
- Click Add Origin and configure settings:
- Name – Enter your organization's Origin name.
- Origin URL – For example, https://www.example.com.
- Redirect – Ignore this option. It has no effect on this feature.
- Click Save.
- Proceed to Part Ⓑ.
- Modify your custom portal HTML by adding the following hidden frame. This effectively sends a 'pluginVersion' postMessage request to the iframe when the iframe loads:
Write code similar to the following on https://www.example.com to handle the postMessage response from the iframe. For example:
- The Okta browser plugin examines all frames on the page, detects that there is one frame of the form https://*.okta.com/app/UserHome*, and then informs that frame that it is installed.
- The plugin detects that it is on an /app/UserHome/plugin-info endpoint that loaded successfully, and then updates its state accordingly by making the four API calls described above.
- You then write code similar to the following on https://www.example.com to handle the postMessage response from the iframe:
Okta requires an authenticated session for this functionality.
The /plugin-info endpoint is denied access if:
- No trusted origin has been defined by the admin.
- The request referrer (such as the parent frame) is not in the list of CORS-trusted origins defined by the admin.
To configure a working example of this feature, create a local web server (for example, Node.js server) to host the simple HTML page below. The following example hosts the page on https://example.com HTML.
The output from running the above code should be similar to this: