000033544 - CreateChangeRequest webservice call with <AccountChange> does not fail on SoD Violations for RSA Via Lifecycle & Governance

Document created by RSA Customer Support Employee on Jul 28, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 4Show Document
  • View in full screen mode

Article Content

Article Number000033544
Applies ToRSA Product Set: RSA Via Lifecycle & Governance (RSA Via L&G)
RSA Version/Condition: 7.0
IssueWhen sending a webservice call to CreateChangeRequest with a request containing an <AccountChange> in order to Detect Segregation of Duties (SoD) violation(s), the Change Request is processed instead of  showing the violation details.
Given the SoD rule with the Entitlement Specification as noted below, a user having or requesting both the Role Administrator and System Administrator roles should result in an SoD violation.

 
User-added image

Now, if a user named 'jsmith' who already has the Role Administrator role requests the System Administrator role using the request xml below through Webservices, the Change Request gets created successfully instead of showing SoD violation details.
The webservice call is shown here:


<Changes>
  <AccountChange>
<Operation>Add</Operation>
<User>jsmith</User>
<BusinessSource>Aveksa</BusinessSource>
  <ApplicationRole>System Administrator</ApplicationRole>
  </AccountChange>
</Changes>

 
The code below shows the wrong response:
<createChangeRequest>
   <Request type="fulfillment">
      <Id>51</Id>
      <Name>00091</Name>
   </Request>
</createChangeRequest>
ResolutionSince Segregation of Duties (SoD) violations are specific to users and not to accounts, the Webservice request should be sent in a <UserChange> tag.
The correct webservice request xml is shown here, that should be sent for user 'jsmith' in the above example.

The webservice call is shown here:
<Changes> 
<UserChange>
<Operation>Add</Operation>
<User>jsmith</User>
<BusinessSource>Aveksa</BusinessSource>
<ApplicationRole>System Administrator</ApplicationRole>
</UserChange>
</Changes>


The correct response is shown here, now with violation details. The EntitledId value refers to the internal database ID of the user.


<Request>
<Violations>
  <Violation>
   <AccountId/>
   <ActionName/>
   <ApplicationId>1</ApplicationId>
   <ApplicationName>Aveksa</ApplicationName>
   <CollectorId/>
   <DetectionDate/>
   <EntitledId>14</EntitledId>
   <EntitlementId>358</EntitlementId>
   <EntitlementName>System Administrator</EntitlementName>
   <EntitlementType>app-role</EntitlementType>
   <FirstName>Dan</FirstName>
   <Id>0</Id>
   <IsDirect>1</IsDirect>
   <LastName>Smith</LastName>
   <Path/>
   <ResourceName/>
   <RuleName>SOD Rule</RuleName>
   <State>CE</State>
   <UserDisplayName>Smith, John</UserDisplayName>
   <ViolatingEntId>358</ViolatingEntId>
   <ViolatingEntName>System Administrator</ViolatingEntName>
   <ViolatingEntType>app-role</ViolatingEntType>  
  </Violation>
</Violations>
</Request>

 

Attachments

    Outcomes