CreateChangeRequest webservice call with <AccountChange> does not fail on SoD Violations for RSA Via Lifecycle & Governance
2 years ago
Originally Published: 2016-07-14
Article Number
000067183
Applies To
RSA Product Set: RSA Via Lifecycle & Governance (RSA Via L&G)
RSA Version/Condition: 7.0

 

Issue
When 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>
Resolution
Since 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>

 

Related Articles

Trending Articles

Don't see what you're looking for?