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

3 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.

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>

Don't see what you're looking for?

Related Articles

Trending Articles