Validating and generating attribute values
Bravura Security Fabric can use a customized plugin to validate, provide values for, or alter the mandatory status of attributes according to business logic.
The process can be summarized as follows:
A user (requester, recipient, or authorizer) updates a change request page (submits or modifies a request).
Bravura Security Fabric sends all attribute values to the plugin.
The plugin determines whether:
The value should be changed to a value specified by the plugin
The value should be changed to a value input by the user
The value should be unchanged
The attribute field should be disabled to prevent further changes
The attribute should be mandatory
The value should be hidden from the user
Bravura Security Fabric redisplays the page. You can configure the plugin so that Bravura Security Fabric displays messages indicating what has changed, or that the user needs to modify the value, and why. Disabled fields are “grayed out”.
The attribute validation plugin overrides configured settings for enforcing validation for attribute groups or individual attributes. Since the plugin can be used to supply values for “hidden” attributes, it is not subject to access controls set for user-controlled attributes.
Note
Some of the functionality provided by the plugin applies to products that you may not have licensed.
The plugin program must be listed in the ATTR VALIDATION PLUGIN field in the Manage the system > Workflow > Profile and request attributes > Attribute logic menu. For Bravura Privilege requests, the plugin program must be listed in the PAM ATTR VALIDATION PLUGIN field instead.
There are no shipped plugins in use with this plugin point. A sample plugin script, attribute-validation-plugin.psl, is located in the samples directory. See how to Write a custom attribute validation plugin below.
Validation of values
Bravura Security Fabric provides some rudimentary validation of values out of the box. The definition of a profile and request attribute allows for configuration of validation rules based on structured text (NN/NN/NNNN for dates or NNN-NNN-NNNN for phone numbers) and use of regular expression.
In many cases advanced attribute validation is required. For example an external source, such as LDAP or SQL, might provide the information for proper attribute validation. In such cases the attribute validation plugin is most useful. It has the ability to look at the information the user has entered and, based on business rules, decide if the value is acceptable.
The attribute validation plugin can use business rules to deny the value entered by the user or accept it. Along the way, the plugin informs the user of the result by displaying a custom message on the Bravura Security Fabric user interface.
You can "turn off" the enforcement of validation rules at the attribute group or single attribute level, in cases where an incorrectly formatted value should not block a whole request. For existing accounts, you can also set validation rules to be enforced only if the value is changed. The attribute validation plugin executes in all cases and overrides configured settings.
Generation of hidden values
On many occasions, the creation of a user object requires a number of attributes with values that are calculated or generated. The best practice dictates that it is easier for a user to only enter information that is required. All other attribute values should be generated. The less interaction that is needed with the requester, the better the usability experience.
Access control lists in Bravura Security Fabric dictate which attribute group are displayed on the user request screen. If a profile and request attribute is not displayed on the request form, it is considered hidden. Such hidden attributes are still available for processing within the attribute validation plugin point.
All hidden attributes can be populated with generated values based on values from other attributes or external sources (LDAP, SQL). The values are not displayed to users.
For example, if the requester enters the country location of the new user (US, Canada, UK), the attribute validation plugin can generate the country code and populate a hidden attribute called COUNTRY_CODE. As a result, the target system where the account is created will accept the country code rather than the country name. In this example, the user works with a human readable country name, where the account creation uses a code number for the country instead.
Write a custom attribute validation plugin
Requirements
The plugin must be placed in the \<instance>\plugin\ directory and runs on the Bravura Security Fabric server. See Writing plugins for general requirements.
Execution points
The attribute validation plugin is executed in various places and during various workflow steps. Attribute validation is required every time the value of a given attribute is changed. Such attribute change operations occur in the View and update profile (idr) module, Requests app, and Workflow Manager Service:
The attribute validation plugin is executed when:
A profile and request attribute value for an existing user is added or modified.
A new user request is submitted, reviewed, or authorized.
A request to add or remove a resource is made for an existing use.r
When the WF ATTRVAL PLUGIN RUN IDR SUMMARY setting is enabled, the attribute validation plugin will execute on the request summary page. This will allow any additional attributes to be added to the request before submission. By default, this option is disabled. You can enable it at Manage the system > Workflow > Options > General.
Note
An attribute validation plugin can generate values for profile and request attributes. The author of an attribute validation plugin is responsible for ensuring that the plugin only sends confirmation to the CGI program that an attribute’s value has changed when the value has actually changed. If the output of the attribute validation plugin defines that the value for a profile and request attribute has changed, the CGI program will not carry out any validation to confirm that the value has changed. The end result is that the value for the "changed" profile and request attribute will be pushed to all target systems where the profile and request attribute is linked to an account attribute. This could create problems if no actual change to the attribute’s value has occurred.
Input
The plugin receives all attributes in addition to the other standard information contained in the session. It also receives information about users’ navigation on the CGI.
Input passed to the plugin is as follows:
"" "" = {
"module" = "<idp|ids|idr|idwfm>"
# Where the plugin is being run from.
"operation" = "<operation code>"
# The possible operation that can be requested; 0 or more
# See Operation codes for a list of codes.
"sessionid" = "<session ID>"
# The session ID for the viewer
"valuessubmitted" = "true|false"
#If the value is false, the plugin is expecting pre-set values, and no
#reservation is done. If the value is true, it is safe to do
#reservation. See Reservation ID on Page 115.
"navigation" "" = { ... } # User navigation data
"attribute" "<attribute id>" = {
"parent" = "<parent attribute>" #present if set
"oldValue" "" = { # Applies to the workflow manager service only
"value" = "<old request value>" # 0 or more
}
"value" "" = {
"value" = "<request value>" # 0 or more
}
} # 0 or more
"recipient" "user" = { ... } # Recipient's data
"request" "" = { ... } # Request data
"requester" "user" = { ... } # Requester's data
"viewer" "user" = { ... } # Applies to Requests app or View and update profile (idr) module only
"model" "user" = { ... } # Data of the model user used in profile comparison
"event" = "<event id>"
# The event context where the plugin is being called.
"postedByAPI" = "<false|true>"
# This key value is present when the request is posted. If true, the request
# is submitted through IDAPI. Otherwise, the value is false.
} For example:
# KVGROUP-V1.0
"" "" = {
"module" = "idr"
"operation" = ""
"operation" = "GRUA"
"preselect_nosgroup" = "1"
"preselect_role" = "1"
"preselect_template" = "1"
"sessionid" = "Scced6c11-2387-4e0d-a09a-d42ed23360cc"
"valuessubmitted" = "false"
"attribute" "APIUSER_CIDR" = {
"value" "" = {
}
}
"attribute" "COUNTRY" = {
"value" "" = {
}
}
"attribute" "EMAIL" = {
"oldValue" "" = {
"value" = "andersch@EXAMPLE.local"
}
"value" "" = {
"value" = "andersch@EXAMPLE.local"
}
}
"attribute" "FIRST_NAME" = {
"oldValue" "" = {
"value" = "Christopher"
}
"value" "" = {
"value" = "Christopher"
}
}
"attribute" "LAST_NAME" = {
"oldValue" "" = {
"value" = "Anderson"
}
"value" "" = {
"value" = "Anderson"
}
}
"attribute" "LUPD_AUTO_ASSOCIATE" = {
"value" "" = {
}
}
"attribute" "ORGCHART_MANAGER" = {
"value" "" = {
}
}
"attribute" "OTHER_NAME" = {
"value" "" = {
}
}
"attribute" "PROFILE_PIC" = {
"value" "" = {
}
}
"attribute" "RBACENFORCE" = {
"value" "" = {
"value" = "T"
}
}
"attribute" "STATE" = {
"parent" = "COUNTRY"
"value" "" = {
}
}
"attribute" "UPDATE_ONLY_CHANGED_ATTRS" = {
"value" "" = {
"value" = "F"
}
}
"attribute" "VIEWABLE_BY_RECIPIENT" = {
"value" "" = {
}
}
"navigation" "" = {
"wfpage" = "selectpredefinedrequestoper"
}
"recipient" "user" = {
"id" = "andersch"
"name" = "Anderson, Christopher"
}
"request" "" = {
"autoressig" = ""
"entryDate" = "1399619891"
"macroStatus" = "U"
"notes" = ""
"prequest" = "PDR"
"reason" = ""
"recipient" = "andersch"
"recipientEmail" = ""
"requestID" = "536C813022AB69E86D9E8BC35E234625"
"requester" = "andersch"
"requesterEmail" = ""
"requesterName" = "Anderson, Christopher"
"reservationid" = "00000000-0000-0000-0000-000000000000"
"segment" = ""
}
"requester" "user" = {
"id" = "andersch"
"name" = "Anderson, Christopher"
}
"viewer" "user" = {
"id" = "andersch"
"name" = "Anderson, Christopher"
}
} Output
The plugin returns the following KVGroups:
"" "" = {
"<errmsg|warnmsg|infomsg>" = "<request message>"
# If supplied, the message is logged, and
# an errmsg is displayed in red,
# warnmsg in orange, and infomsg in green.
"retval" = "0" # Mandatory; zero is success and non-zero is failure
"reservationid" = ""
# Optional reservation ID but required if it was passed into attribute
# validation or idm-suite id plugins
# See "Reservation ID" notes below.
"attribute" "<attribute ID>" = {
# Required for each attribute to be modified or failed.
# Optional if no change.
# All the following are optional:
"<errmsg|warnmsg|infomsg>" = "<attribute message>"
# If supplied, logged and displayed for the attribute
# in addition to any request message.
"failedValidation" = "0|1"
# 0 = the attribute was validated
# 1 = the attribute could not be validated
"forceRequired" = "0|1"
# 0 = the attribute value is not required
# 1 = the attribute value is required -- the user cannot proceed
# until a value is supplied
"forceDisabled" = "0|1"
# 0 = the attribute is enabled -- the value can be changed
# 1 = the attribute is disabled -- changes are disallowed
"display" = "0|1"
# 0 = the attribute is hidden
# 1 = the attribute is visible to the user
"modifiedValue" "" = { #if values are modified
"value" = "<first_value>"
"value" = "<second_value>"
...
}
}
...
}Reservation ID
The reservation ID is a unique ID that is recorded in the database for the life of the request. It can be passed as input to other plugins along with request details; for example template and role filter plugins. It is also passed as input into subsequent runs of the attribute validation plugin.
If there is no reservation ID for a request, then the value is 00000000-0000-0000-0000-000000000000. Once a reservation has been made for a request, the unique ID looks something like this: 4dc9e603-0e50-4503-b152-4a76de77a5f6.
Examples
The following are examples of KVGroup plugin output:
To replace an attribute value then disable the field:
"attribute" "LAST_NAME" = { "forceDisabled" = "1" "modifiedValue" "" = { "value" = "Johns" } }To change an attribute from optional to required:
"attribute" "OTHER_NAME" = { "warnmsg" = "You must provide a middle name" "forceRequired" = "1" }