Expand my Community achievements bar.

Automation of Adobe Target Access Management using UMAPI

Avatar

Level 2

11/17/21

Description

Automation of Adobe Target Access Management using UMAPI

 

Why is this feature important to you:

As a Financial Services organization we would like access management of Adobe Target roles to be automated using the Adobe UMAPI.  The automated process helps us to be compliant, with the right monitoring and controls in place and no manual touches.

 

How would you like the feature to work

We would like Adobe Target access management to be fully automated* using the UMAPI same as other Adobe products in our organization such as Analytics, Launch, et al. This would also help us be compliant and remove the vulnerability written against Adobe Target.

 

More than happy to review our current set up with the Product team and support any way we can.  Adobe Team knows how and where to reach Mary Daniel.

 

Current Behavior

Adobe Target has 4 roles.

Approver - Can create, edit, and activate or stop activities.

 

Editor - Can create and edit activities before they are live.  Editor cannot approve the launch of an activity.

 

Observer - Can view activities. Observer cannot create or edit them.

 

Publisher - Similar to the Observer role, Publisher can view activities.  Publisher cannot create or edit them. However, the Publisher role has the additional permission to activate activities.

 

My organization uses the Adobe UMAPI to automate access management.  *We use Active Directory Roles in SailPoint to request and manage access.  These roles are aligned with Product Profiles/Workspaces in the Adobe Admin Console.  Once the role is approved/removed in our access management platform for a user, the AD role syncs with the UMAPI and automatically administers the access in the Adobe Admin.

 

When an Adobe Target user is granted a role, irrespective of the whether the user is approved for Editor, Publish, Approver or Observer, the access defaults to Observer in the Admin Console. As result, once the access is administered in the Admin Console, System Admin is then required to follow up with a manual workaround involving switching the user to the correct role approved through our Identify and Access Management.  This has caused a Vulnerability to be written against the product.