This article explores how standard Okta self-service access requests and Okta Workflows can be used to implement Just-In-Time access to Okta Advanced Server Access. It assumes some understanding of Okta, Okta Workflows and Okta Advanced Server Access objects and capabilities.
Article contents:
Just-In-Time Access with Okta Advanced Server Access
A common request with Okta Advanced Server Access (ASA) is for just-in-time server access. This can be implemented in one of three ways – group membership, on-demand provisioning and preauthorizations.
As ASA server access is tied to group membership in ASA projects, and the Okta Identity Cloud platform is managing group membership, you could dynamically allocate/de-allocate access using group rules or a request-based mechanism. This could include automation with workflows, such as the Okta Workflows Assign Temporary Group Memberships template.
With a user in the appropriate group, ASA will provision that user. There is a project “On Demand User TTL” setting that is disabled by default, meaning a user is provisioned as soon as they are associated with the project. If one of the TTL values is selected ASA will only create a user on a server when a user attempts to access it, and users will be removed when the session ends or after the configured period. See https://help.okta.com/asa/en-us/Content/Topics/Adv_Server_Access/docs/on-demand-users.htm.
ASA also provides a preauthorization capability. In addition to being in the appropriate group, a user also needs to be preauthorized to access servers in a project. Pre-authorization is set at the project level in ASA – some projects could require pre-authorization whereas others don’t. Perhaps the server risk analysis calls for some servers to have pre-authorization and you could put them in their own project.
A user can be preauthorized in the ASA Admin Console by an ASA admin. Creating a preauthorization involves setting an expiry date/time for a specific user.
Creating a preauthorization involves selecting the user and an expiry date/time.
In addition to using the ASA Admin console, there is an ASA API to work with preauthorizations (https://developer.okta.com/docs/reference/api/asa/projects/), including fetch, create and update a preauthorization, and list preauthorizations for a project. This could be used from a service request system like ServiceNow, to request JIT access to servers.
The API to create a preauthorization is implemented in the Okta Workflows ASA connector (https://help.okta.com/wf/en-us/Content/Topics/Workflows/connector-reference/advancedserveraccess/actions/createpreauthorization.htm) and is shown in this article. Preauthorizations will automatically expire at the expiry date/time.
The rest of this article will look at how we can implement a preauthorization request function in Okta using Okta Workflows (and how we can cleanup after).
Request ASA Preauthorization With Okta and Workflows
The mechanism involves standard Okta features and Okta Workflows, as well as ASA.
Overview
To demonstrate the component and flow, I have a setup based on the need to preauthorize access to a set of Linux servers. The end goal is that the user needs to be able to SSH to a specific Linux server, but in addition to being in the right group, they also need to be preauthorized with an approval process.
The components and flow are shown below.
The sequence is:
- The user uses the Self Service component of the Okta Dashboard to request access to an application (a dummy application called “req Linux Server Access”). There may be a manager approval on the flow. Once approved the user is added to this application in Okta.
- The user added to application event in Okta triggers a workflow. This workflow will set a future date/time,
- Add the user preauthorization (using the ASA connector) and then
- Store the user and date/time in a Workflows table (which also acts as an audit trail)
- Periodically a second workflow will run through all the entries in the Workflows table to determine the expired preauthorizations and remove the associated user from the Okta app. This is needed because the preauthorization will automatically expire in ASA, but the user will still be assigned to the request app in Okta – if they weren’t removed, they couldn’t request it again.
The rest of this article will look at how this is implemented and used.
Preauthorization Components and Flow
This implementation has components in Okta (Identity Cloud), Okta Workflows and Okta ASA.
Okta Identity Cloud Configuration
Within Okta there is a dummy application for the user to request, and the access request mechanism.
The dummy application, called req Linux Server Access, is a bookmark app that will be exposed via the Self Service access request mechanism. It only needs a name/label, an icon (if you want) and a dummy URL. It will not be displayed to the end user or on the mobile app. It will never be used for SSO.
The access request mechanism is the legacy Okta Lifecycle Management (LCM) self service access request mechanism. This will be replaced by the Access Requests feature of Okta Identity Governance in the future, but the outcome is the same – a user can request the app.
In this example, no approval flow has been enabled, but it could have been set to require manager or app owner approval. As it is, the user just needs to request the application and it will automatically be granted.
Okta Workflows Configuration
For the request processing, there is one table and one flow (there are additional flows in the cleanup, covered later).
The table is used to store all requests, serving as an audit trail, but is also used in the cleanup. Each row represents a request and contains who requested it, when, who it’s for (in this implementation it’s the same user), when it expires and when it was cleaned up.
The MAIN – Add User to ASA Preauth workflow contains the event trigger and six cards.
The event trigger is the User Assigned to Application event in Okta, looking for a specific application (the Id of the req Linux Server Access application).
This event will return details of the administrator, the Okta user profile and the application user profile. To update ASA we will need the ASA username, which is the short Okta username (e.g. the bit before the @ in the Okta username). The Okta username is stored in the Alternate ID field. We want to strip off the ‘@’ and following parts to get the short username (Split and At cards).
In the above example, Alternate ID is “kent.brockman@deadwood.com”, so we split on the ‘@’ into an array and get the first entry of “kent.brockman”.
The next two cards (Now and Add) determine the current date/time and add two hours to it.
The next card is the ASA Create PreAuthorization card. It requires three parameters, the short username, the project the user is to be preauthorized for and the expiration date/time (which is the current time plus two hours.
The last card (Create Row) will write the details of the request into the PreAuth History table.
Okta ASA Configuration
The ASA configuration involves a project with the Require Preauthorization (Preauths Required) flag set.
When the workflow above runs, you can see the preauthorization in the ASA Admin Console for the project.
That is all that’s involved in the setup to request preauthorization. The last section of the article will look at the cleanup process.
Cleanup Components and Flow
As mentioned earlier, the ASA preauthorization feature will automatically expire at the expiry date/time. However as we’ve added an extra component to this flow, the dummy request app, we need to clean it up. We can do this with a scheduled workflow leveraging the information we stored in the table.
This is done entirely in Workflows, with a main flow, a sub (helper) flow and the table shown above.
The main flow could be run on a timer or on demand. There are three execution cards.
The first card is determining the current date/time.
The second card is searching through the PreAuth History table looking for all rows where the expiry date is less than the current date. This is just an example, and you would want something more scalable in a production deployment as this table will continue to grow.
The last card calls a subflow for each row returned from the table. The subflow will be passed the PreAuth History row as an object.
The first card extracts the row id, user id and cleanedup date/time. If the cleandup entry is empty, the flow continues.
The third card will Remove User from Application – remove the user in the table row from the req Linux Server Access application.
The last card updates the row in the table (using the row id from earlier) to set the cleanedup date/time to now.
Running the flow results in multiple executions of the subflow, one for each row with an expired date/time in the past. The subflow will remove the user from the application and update the table.
This concludes the article. We have shown how we can use standard Okta self service access requests with a dummy app and an Okta workflow to create an Okta ASA preauthorization to allow temporary access to a server.
Sample Code
The workflows example described above can be downloaded from https://github.com/iamse-blog/workflows-templates/tree/main/dae-asa01-Preauthorizations
