Information Technology Reference
In-Depth Information
Once the robot credentials have been set and the workflow has been saved, any
robot credential association set in the workflow is stored. From this point on, the
executable and the computing resource de
ned in the workflow nodes set up with
robot credentials cannot be changed, unless the robot credential association is
removed. This ensures that end users cannot run their own application with the
robot credentials.
If the workflow developer opens a workflow node that already has robot cre-
dentials de
ned, then it is possible to remove the robot credential association. It is
important to note that the
role is not needed to remove
the robot credential association. Once the robot credential association has been
removed, the target computing infrastructure and the executable of the workflow
node can be overridden.
The above-described mechanism applied in WS-PGRADE/gUSE
“
RobotPermissionOwner
”
s user inter-
face ensures that if a given workflow node has some sort of robot credential
assigned, then the users do not have the possibility to modify the target computing
infrastructure and the executable de
'
ned for the node unless the robot credential
association is removed. Once the robot credential association is removed, the users
have to provide their own credentials to run their own applications.
Storing Robot Credentials
Once a robot credential association has been set for a workflow node and the
workflow has been saved, WS-PGRADE/gUSE stores the robot credentials. The
storing mechanism conforms to the following policy:
The credentials are stored where they are really needed. This is the job sub-
mission component called DCI Bridge in WS-PGRADE/gUSE.
The stored workflow description contains only a reference to the robot credential
stored on the DCI Bridge.
This policy ensures that users cannot acquire robot credentials.
Robot credentials consist of the following components: the executable used and
the actual authentication data. The latter is similar to the authentication data of user-
provided credentials, and depends on the type of authentication applied by the
target computing infrastructure:
Basic authentication: in this case the username and password are stored.
SSH key: in this case the SSH key pair
is private part is stored, along with a
username needed to log into the resource.
'
X.509: in this case storing the X.509 proxy is not feasible (being a short-term
credential) nor allowable (as robot X.509 certi
cates must not leave a secure
token). Instead, the MyProxy availability of the robot certi
cate is de
ned.
SAML: in this case the SAML assertion is stored.
Search WWH ::
Custom Search