- 24 May 2023
-
DarkLight
-
PDF
Run as Another User
- Updated on 24 May 2023
-
DarkLight
-
PDF
The Pronghorn class has a function called sudo
that provides the ability to run a given method using the permissions of a different user. This is an asynchronous function and can only be used to call asynchronous functions.
Accessing the Pronghorn Class
An instantiation of the Pronghorn class is made by IAP on startup. It is exposed as the global pronghorn
object. IAP applications and adapters may reference the pronghorn
object.
Sudo
Arguments
The sudo
method takes three arguments:
Argument | Description |
---|---|
Object userData |
This JavaScript object varies based on the implementation of your installed AAA adapter. This value should match the object passed to the login API. |
Object action |
This JavaScript object represents the method to be called. It contains three keys: 1) service, this is a string that is the unique name of the application or adapter where the method resides; 2) method, this string is the name of the method; and 3) parameters, this is an array of parameters passed to the function minus the callback. |
Function callback |
This callback method will be called with the result of the executed method. |
Example Implementation
// Standard user object used for authentication
// We will become the user named test
const user = {
"username":"test",
"password":"test"
}
// Call to getDevice on an adapter named 'myDeviceAdapter' to get a device named 'ATL0'
// N.B. Even though getDevice expects a callback, it is left out here.
const action = {
service : 'myDeviceAdapter',
method : 'getDevice',
parameters: [
'ATL0'
]
}
// Call the sudo function and provide the callback here.
pronghorn.sudo(user, action, (result, err) => {
if (err) {
return console.error(null,err)
}
// print out the data returned from the call
return console.log(result);
});
Auditing
Whenever the sudo
command is used, a new session is created in addition to the one calling sudo
. The executed method is run under that new session. Since there are two different sessions, there are two different audit trails. Both the session that called sudo
and the sudo
session itself are automatically flagged for audit serialization.