RapidIdentity Product Guides - 2019 Rolling Release

Alternate Claim Account Action

This alternate action is used to bypass built-in RapidIdentity Portal logic and instead allow an arbitrary RapidIdentity Connect Action Set to provide Claim Account functionality. RapidIdentity Portal performs the necessary authentication/authorization/validation on the request then invokes the pre-defined Action Set on the configured RapidIdentity Connect instance.

After a Claim Account request has been validated, RapidIdentity Portal generates a new random password based on the target account's current Password Policy. This new password will be sent to the RapidIdentity Connect Action Set and it is essential that the Action Set updates the password of the target account with this new password as part of its logic. If this fails to happen, the Claim Account functionality of RapidIdentity Portal will be broken.

Action Set Parameters
Table 323. Parameters

Parameter

Description

target_dn

The DN of the target of the operation (whose profile is being claimed)

perp_ip

The IP address of the perpetrator of the operation (who's performing the operation)

audit_event_id

An audit event ID which may be used to correlate any audit log events from invoked Action Set to the audit log event generated by the call to the RapidIdentity Portal API

newPassword

The randomly generated temporary password that the DSS action should set for the account



Action Set Parameters

The following example shows a record_string value indicating that the target's LDAP entry should have a givenName value of FirstName, a sn value of LastName, a multiValuedAttribute attribute with two values: value1 and value2, and no values for attribute deletedAttribute.

{"givenName": "FirstName", "sn": "Last Name", "multiValuedAttribute": ["value1", "value2"], "deletedAttribute": null}

Action Set Return Value

{ "success":"<boolean>", "message":"<string>", "new_dn":"<string>" }

Table 324. Return Fields

Field

Description

Required

success

Whether RapidIdentity Portal should consider the action as successful

no, defaults to false

message

Optional message which will be passed through to the API response and ultimately to the UI.

no

new_dn

In the event that the profile update results in the target object being moved in the directory, this value should be populated with the target's new DN.

no



Example

{"success": false, "message": "The operation failed because...."}

{"success": true, "message": "The account was claimed successfully", "new_dn": "cn=targetDN,ou=newOU,dc=example,dc=com"}