PowerBroker for Unix & Linux (PBUL), BeyondTrust’s gold-standard solution for Unix/Linux privilege management, comes with a very powerful and flexible Policy Engine that enables organizations to satisfy even the most complex privileged access requirements. In this blog, I will explain how that Policy Engine leverages an API for third-party solutions, such as cloud applications and DevOps tools, to enable full orchestration across an environment, in this case – Okta.
With PowerBroker, it’s possible to interface with Okta for both step-up authentication and to verify that users are properly authorized via a Role, Group, or a specific permission before allowing them to execute a specific command on a specific server.
If an administrator wants to issue a command to restart a server instance in a cloud or DevOps environment, the PBUL Policy Engine can first verify that the user is a member of the appropriate permission Group, and that the user is authorized for the specific server instance. Other conditions can also be included, like time of day, the day of the week, the user’s location, and any other third-party solution scripted through PBUL policy.
[caption id="attachment_26368" align="alignnone" width="650"]
Step-up authentication for the useradd and userdel commands. 2- Okta Vrify Push is selected for both.[/caption]
[caption id="attachment_26367" align="alignnone" width="292"]
Okta mobile application and Push Verify task to Approve.[/caption]
To see how this works, let’s look at the example below. First, we need to define a couple of sample groups in Okta. Our sample user, Sally Duncan, is a member of the DevOps Group. The groups are shown below (not her membership):
Then, we use a simple test script (okta_test.sh) to our PowerBroker policy:
## The following user, sally.duncan, is used to test Okta query.
if (user in { "sally.duncan" } && basename(command) in { "okta_test.sh","okta_test"}) {
# do not allow these commands to be delegated
print ("user called okta_test.sh");
if (basename(command) in { "okta_test.sh","okta_test"}) {
print ("command is okta_test.sh");
include '/etc/pb/okta_functions.conf';
RetrieveOkta_Group();
#print("We are now using print in poc20 policy for Okta");
#print(OktaDATA);
DELIM=",";
OktaFIELDS=split(OktaDATA,DELIM);
print(OktaFIELDS);
COUNT=0;
COUNTER=0;
TEST=split(OktaDATA, "\n");
for Lines in TEST {
TEST2=split(Lines, ",");
COUNT=length(TEST2);
COUNT2=( COUNT -1);
while ( COUNTER <= COUNT2 ) {
#print(COUNTER);
#print(TEST2[COUNTER]);
if ( TEST2[COUNTER] == "DevOps" ) {
print("Congratulations - you are a member of the DevOps Group in Okta, so you are authorized to execute this command");
COUNTER++;
}
else
{
COUNTER++;
}
} # End while
COUNT=0;
COUNTER=0;
} # End for
}
accept;
#reject("This is a restricted command okta_test.sh -- '" + basename(command) + "'.");
}
When you execute the script as a part of a “test” policy, you are able to determine the Okta group membership as shown below:
This is a simple example, but it demonstrates three very important things
- The power of the PowerBroker for Unix & Linux scripting language to integrate into third-party solutions.
- The integration from PowerBroker for Unix & Linux to support group membership of Okta users.
- The support of PowerBroker for Unix & Linux in DevOps and Cloud environments in support of next-generation technologies.
Michel Bluteau, Sr. Sales Engineer, BeyondTrust
Michel has been interfacing with many organizations in different verticals around the world, over the last decade, trying to capture Requirements and Use Cases in Identity Management, Compliance, and more recently Privileged Account Management. Michel’s expertise with various platforms including SAP, ServiceNow, .NET and Java, allows him to contribute to integration and share his experience and solutions. Recently, Michel has also been focusing on the User Experience and how to leverage Web Services API made available more and more for both on-premises and cloud based applications and platforms.