OIG Access Requests – Automate Out of Country Requests and Security

Overview

The purpose of this post is to configure an access request for end users to request when they are going to be out of the country.  Oftentimes, IT teams like to lock down their environment so their employees can only access their applications from one designated country or area (maybe we call this US only).  When employees need to work remotely, outside the US, the IT administrator receives an email, slack, or ticket, and then needs to manually exclude users from existing security policies.  This document will walk you through how we can automate this and keep our environment more secure/dynamic.

Summary – What we will build

• 1 Access request
• 1 Okta Group
• 1 Security Rule (in authentication policies)
• 5 Workflows
  1. Track out of Country Event (Delegated Flow)
     1. This flow will receive the questions answered and the approver information from the Access Request and log this information to an Okta table and Jira.
  2. Add User to Out of Country Group (Scheduled Flow)
     • Checks the table and compares today to the start date of the “out of the country request.”  Calls the helper flow (3) to do the rest.
  3. Helper – Remote Start Date (Helper Flow)
     • Receives employees who will be out of country today and fires off notifications via slack/email, promotes the Jira Ticket to “In Progress”, and automatically adds the user to an out of Country Group. This out of country group will have a specific rule set up in our authentication policies which will enforce a different authentication regulation on the user while they are out of country and allow them to access certain applications.
  4. User Back in Country (Scheduled Flow)
     • Checks if today is the day they are returning from their travel in the table, checks if the user is currently in the out of the country group, and calls a helper flow to do the work.
  5. Helper – Remove user from out of country group (Helper Flow)
     • Removes the user from the out of country group if it’s after their last day there, promotes the Jira Ticket to Done, and notifies the administrators.

Requirements

1. Access Requests
2. Workflows
3. Jira – dev trial here.  Can also use any other Ticketing system that has an API available to promote/create tickets/issues.
4. Slack or Teams
5. Gmail or O365 Mail

Workflows Config

Create workflows folder – OIG Out of Country Requests. 
Set up delegated flow – Track out of Country Event  Create these inputs on the event trigger card and then save the flow.

1. country
2. email
3. startDate (change to date type) – hover over tile and click arrow
4. endDate (change to date type)
5. reason
6. approver

Access Requests Config

Save the flow > turn it on > go into access requests dashboard > Settings > resources tab (at top) > workflows tab (on left) > update your flows (button) to get it to pull through.  This might take a minute or two so work through the next pieces, come back, and refresh later.

While here, go to configuration lists tab (at top) – create new custom list called Approved Country List. Add a few countries:

1. Canada
2. Japan
3. Mexico
4. Argentina
5. Germany
6. France
7. Other

*Include whatever countries you’d like and an Other category as well.

Workflows Config P2

Create a table in the same workflows folder – Outstanding out of country requests
Add the following column headers. Capitalization is important here – I like camelCase.  If you use something different be mindful of that for the rest of the doc.

1. country – String
2. email – String
3. startDate – Date
4. endDate – Date
5. reason – String
6. ticketId – String
7. isOutOfCountry – Boolean (default – false)
8. approver – String 

Back to the delegated flow Track out of Country Event 

1. Create two text compose cards.  I also added two Date to Text cards to format the start date and end date of the trip.
   1. Go ahead and format what you want to say in our ticket and notifications.  I wrote out {email} needs access in {country} in the first text compose card.  

For the second part of this same flow, go ahead and add a create issue card with Jira and a create Table Row card.
In the Jira field summary I dragged the first text compose card output we created in the image above.  Similarly, I added the description from the second text compose card we create in the previous step.

This concludes our delegated flow, Track out of Country Event, that interacts and receives information from our access request that we are going to create next.  All we are doing is taking in the information from an access request, logging a ticket, and creating a row in a table that we can later read in from and take action the day the user has requested access out of the country.
Make sure the Track out of Country Event flow is on and let’s go back to access requests to put it to use.

1. Go to access requests and create a new request type.
2. Name this Request Access while Out of Country (or something similar).  Go ahead and select a team and an audience as well (I have selected my IT team and Everyone.
   1. 
3. Please add the following questions to your flow
   1. Business justification for Access (Text type)
   2. Start Date (Date type)
   3. Return Date (Date type)
   4. Where are you traveling? (Dropdown > data source = Approved Country List – we created this in our settings in a previous step).
      1. Add one final question that is conditional on (d) above: If other – please list the country (Text type).

4. Add the following Tasks & Actions to your flow

1. Approval Task – IT Approval (assigned to IT team)
2. Action – Run a Workflow – select our delegated flow.
   1. Call this Track out of country event (approved country list)
   2. 
3. Action – Run a Workflow – select our delegated flow.
   1. Call this Track out of country event (other country list).  The reason for this second workflow option is because they might answer “Other” and provide the country that is not listed.
   2. Please note the only different field between this and the previous run workflow is the country is switched to “if other – please list the country”
4. Save the request and publish it.

You should now be able to go and request access to be out of the country and you should see the information the end user answered in the questions in the workflows table (Outstanding out of country requests) we created previously.

We are going to create 4 more flows.
2 of these flows will correspond to the user being added to the out of country group and the other two will correspond to the user being removed from the out of country group.

1. Create a scheduled flow. Call it Add user to out of country group. This should run daily at 9:00am or whatever your preference is. Mimic the screenshot provided below. You will need to leave off the last “For Each” card until we create the helper flow.

2. In this flow we are comparing the current time to the start date (when the user goes out of the country).  I added one day to the current time because sometimes servers log times at 12:00 UTC or midnight.  Allowing for one day of leeway time ensures the user will have access the day they need it.
3. We search the table for rows that are less than or equal to the tomorrow date we created.  What this really means is, grab the rows in the table where the start date comes before now (plus 1 day).  Meaning the start date has already happened. Also, add isOutOfCountry = false.  This ensures that we aren’t adding people to the group that are already out of the country.
   1. 
4. Let’s create the helper flow now.  Call it Helper – Remote Start Date. Follow the provided screenshot below.

5. In this helper flow we are receiving the Remote Employee (a row in the table).  Please click the dropdown next to where we type Remote Employee > select object type.
6. The get multiple card pulls out the individual fields from that object being received.  We will pull out all the fields from that table (INCLUDING Row ID).
7. List Users with search we will want to select the first matching record on the email field which yields the ID of the user that we will feed to the Add User to group card.
8. Now, if you have a group already created for your out of country users, you can simply navigate to that group in your Okta Admin console and you should be able to grab the group ID from the end of the URL.  If you don’t have a group, create one now. You will copy and paste the Group ID from the URL into the Add User to Group card in the flow.

9. Once you’ve done this, you can go back to the Add user to out of country group flow we added in step one and finalize the flow by adding the “For Each” card.  Select the helper flow we just created (Helper – Remote Start Date).  See image below.  It’s important that you set the item on the bottom to an object so that our helper flow can receive it correctly.

10. In the same helper flow (Helper – Remote Start Date), let’s go ahead and add some notifications and promote the ticket in Jira. This comes directly after the Add user to group card.

11. The Difference Time card just allows me to tell the admins how long this user is going to be out of town for.
12. The Date to Text card allows me to format the start date in my text Compose to make the date more readable (11/02/2023), ect.
13. Create the text compose card that we will add to the ticket, email, and slack our administrators with.  This can be whatever you’d like.  I let my admin know the user was added to the out of country group and that the user will be removed in {X} days (depends on return date).
14. For the Jira card, in order to promote the ticket, the “Transition To” field needs to match what you have in Jira for the different phases.  By default I believe there is “To Do”, “In Progress”, and “Done”.

15. Let’s notify our admin via email and slack.  If you are savvy enough, you can add these fields to the request or look up the user via their ID (Read User Card) and find their manager or look up the Slack User ID via the slack admin (read user card) and pass the users email to find the ID.  In my case, I hard-coded in my admin user.  Additionally you could create a subject for the email that’s customized by I standardized mine to User added to the out of country group.
16. Lastly let’s set the update row (Row ID we grabbed earlier from the step 4 screenshot). All we are doing here is changing the isOutOfCountry field to true in the table.  So the next time the scheduled flow kicks off we don’t re-rerun the Helper to add the user to our group and notify the admins again.

Here’s some example screenshots of my notifications for email, slack, and Jira. We can see my Ticket was promoted to In Progress while the user is out of country and in the group.

What have we accomplished so far?

1. End users should now be able to make an out of Country Request.
2. Once IT approves it, the user will be added to a local Okta Table with all the information about the request (country, reason, start date, end date, ect).
3. Our scheduled flow will continually check if the user’s out of country start date has occurred, and add them to the group and notify the admins.
4. We can take this a step further and set up our security policy for our out of country group.

Let’s now set up the security policy.

1. Go to the admin console > Security > Authentication Policies
2. Click any policy you want the out of country group security rule to apply
3. Create a rule called Approved Out of Country Group Security Policy. Be sure to make this rule applicable to the Out of Country Group Only.

4. For more on security policies best practices and following NIST Guidance please visit: https://sec.okta.com/articles/2023/03/setting-right-levels-assurance-zero-trust. From this document there is a great table I will share here.  We will want to take into consideration the fact that they are working out of the country and apply our policies as if they are higher risk Authentication attempts.  This article does a fantastic job detailing all the specifics.  Please read through that document and choose factors and reauthentication frequency policies that fit your risk tolerance.  I set mine to password/IDP + another factor, phishing resistant, and hardware protected only.

5. You can see now, if I am blocking countries outside the US in rule 2, any user that is in my out of country group in rule 1 will abide by the authenticators I have specified there to access their applications.  Please note that the rules are evaluated in priority order.  So if my user is in the “Out of country” group but the block risky network zone comes first, that rule will trigger and deny the authentication.  Order matters!
6. We could take this a step further and alter our global session policies for our Out of country users as well but I won’t go into that here.  More information on setting up global session policies here: https://help.okta.com/oie/en-us/content/topics/identity-engine/policies/about-okta-sign-on-policies.htm

Let’s now finish our final two flows.  It’s going to remove the user from the group and the Okta table when the user’s out of country end date is the same date as today.

1. Create a Scheduled flow called User back in country (or something similar).  Set the flow to run daily or whatever cadence you prefer (12 hours, ect).

2. The first card will be to search the table for where the endDate comes before the current time (pulled from the scheduled flow itself) AND where the isOutOfCountry value is true. (see image below).
3. Leave the “For Each” card out of the equation until we set up our helper flow for now.

4. Lets now build the helper flow and call it Helper – remove user from out of country group.

5. This is very similar to our adding help flow but doing the reverse.  Make sure the Remote Employee in the helper flow card is an object.
6. In this helper flow we are receiving the Remote Employee (a row in the table).  Please click the dropdown next to where we type Remote Employee > select object type.
7. The get multiple card pulls out the individual fields from that object being received.  We will pull out all the fields from that table (INCLUDING Row ID).
8. List Users with search we will want to select the first matching record on the email field which yields the ID of the user that we will feed to the Remove User from Group card.
9. Now, you can simply navigate to that group in your Okta Admin console and you should be able to grab the group ID from the end of the URL.  You will copy and paste the Group ID from the URL into the Add User to Group card in the flow.

10. In the same flow, Helper – remove user from out of country group, after the remove user from group card we will add the following

11. The first card transforms our end date into a more readable text.  I used MM/DD/Y for the formatting.
12. Create a text compose card to say that the user returned from the country with the an end date of the output from the formatted date.
13. Transition the issue in Jira to done
14. Slack the administrator.
15. Optionally, send another email.
16. Delete the Row in our table with the Row ID passed to the helper.
17. Please don’t forget to go back to the flow User back in country and add the “For Each” card that calls this helper flow we just created. See image below.  Don’t forget to choose the correct helper flow and change the item to an object if it is not already. (see image below)

Finally, we can turn on all the flows and let users make out of country requests and not have to deal with opening up specific countries to access our applications.  We can keep restricting all of the countries we want, and allow only our users that have been approved to access their resources with a specific (hopefully more secure) policy that we choose and from an administrative point of view, we can knock this approval request out directly from Slack, Teams, or our dashboard and not have to worry about any of the manual pieces in between.  We also have a full log of everything in the access requests reports and Jira plus additional reminders in Slack and Gmail.