User Access Management: Part 3 - Practice makes perfect!
This is a detailed walk-through (and a downloadable link to a practice model!) that you can follow to get started on your UAM journey.
High-Level Architecture
How User Information is updated via import
|
The User import definition in the screenshot to the right shows what can be updated: The import key is Email Address. Target Data items are the standard attributes that you can change. Note: If a user already exists, you cannot change First Name and Last Name. You can only change Role and Single Sign-On. Target Access items are for Selective Access. Note the bulleted items below for Selective Access:
|
 |
The UAM model must be able to provide the above information for each planning model as in the example below:
Common Structures
This article covers two different ways to implement UAM and the common Structures and Lists are covered here: Directory Source, Anaplan User, Models, and Model Roles
Directory Data
The Directory Data can be from the source systems that are valid for your environment. These can include Directory Systems (e.g. LDAP, Active Directory), Identity Management Systems (e.g. Okta), or Employee Data (e.g. Workday). What is common between these sources is information about potential Anaplan Users, such as email address, role, and organization, that are useful for correctly assigning a user to a particular model. In some cases you may source from a ticketing system that sends approved access request information (e.g. ServiceNow).
The Starter model will allow you to choose which person to add as an Anaplan User using their email address. The User L1 column above connects to the Anaplan User list (via FINDITEM) and easily identifies whether someone was already added.
User list - User L1
The key for User L1 is the email address. The other person-specific information needed when adding a user to a model are first name, last name, and whether to use SSO. We recommend SSO since it is inherently more secure so you can explicitly set this to always be true.
The Starter model does include the ability to replicate the access of an existing Anaplan user.
Models and Roles - Model L1, Model Role L2
Model L1 contains the list of current Anaplan models that you will be updating from UAM.
Model Role L2 is a child of Model L1 and is a numbered list so you can have duplicate role names across different models. The Role name you enter also acts as the Display Name for the list item.
Model Schema - Option 1 (No Selective Access)
We recommend this option if Selective Access does not have to be maintained in UAM. In this case, User to Model assignments is defined by a specified role at the desired intersection.
This is easier to implement than Option 2 (which supports Selective Access - covered later in this article).
User to Model mapping
The module INP User Model V1 is dimensioned by User L1 and Model L1. The critical line item is "Role" and selecting a value here creates the mapping information that will be exported to the planning model. The SSO flag is also set here, normally always TRUE because it is the more secure option.
Note: the selected Role is a dependent list so you can only choose the roles specific to the model as defined in the Model Role L2 module covered earlier.
Export User Model Information to Planning Model
Each Model needs to have its own saved view in User Model L2, with the appropriate filtering mechanism as in the screenshot below which shows the view for the P&L model.
The view is filtered by Status, Role Assigned (not blank), and specific Model as in the screenshot below.
Import User Model information into the Planning Model
The screenshot below shows elements of the saved view mapped to the User information in the Planning model.
Define Selective Access directly in Planning Model
Option 1 does require you to go into the Planning Model and update Selective Access as shown below.
Model Schema - Option 2, with Selective Access
In order to support Selective Access which is detailed access items per model per user, a hierarchical structure is needed. In this case: User L1 / User Model L2 / User Model Selective Access L3.
User to Model relationship
User Model L2 is a numbered list and you add models as children of User L1. The module below (INP User Model V2) contains the properties that define access: selected model (Model L1), Role, SSO, First Name, and Last Name. The exported view looks very much like the V1 module equivalent.
Defining Selective Access
Selective Access (User Selective Access L3) items are added as children of User Model L2. This is a numbered list, and each row defines one list item that the user has access to. The item name is just a sequential number.
Each specific dimensional element (by row) is defined for selective access Read and/or Write, for that level of the hierarchy. Every list that requires selective access should reflect the latest structure in the planning model. That is why the architecture early in this article shows list data being pulled into UAM.
In the screenshot below you see that you pick the item for selective access and if this is a numbered list item, the "#Name" equivalent is pulled in since that is required for selective access. This too must come from the planning model.
Export Views to update the Planning Model
Similar to Option 1, you need saved views for User to Model assignments and User to Model Selective Access. The examples below show an extra export for setting role to “No Access” which clears all existing Selective Access Items before being re-assigned in a subsequent import action. This is not a recommended approach as it will remove data associated with the user (e.g. user filters). This is here to reflect the challenge of changing existing Selective Access Items after the initial assignment.
Each Selective Access item is a separate row for a given user as shown in the below screenshot and is filtered explicitly for a particular model. Note the #name value for numbered list items.
Selective Access Import Definition for planning model
You can see in the screenshot below the user information mapped to selective access fields.
Automating Updates to Planning Model
You can automate the security updates from UAM to planning models by leveraging CloudWorks to periodically update security. CloudWorks uses an internal user ID that can run model to model integrations and this means the UAM administrators do not need any access to the planning model.
You can schedule the security update to run daily or more frequently. Or if you need security to update immediately you can ad hoc run the import in the planning mode. The person running the process in the planning model must have WSA (full access) rights and have read access to the UAM objects.
CloudWorks Example
- Step 1: In the planning model, create a process that runs the security import from UAM
- Step 2: In CloudWorks, create a process to execute the Security update
- Step 3: Schedule your new CloudWorks process
Additional Functionality (not in the Starter Model)
Here are some other considerations you may want to explore:
- Map Directory Source data to a role or selective access to automate that part of model authorization.
- Add a History Log of User changes with date-time stamps to simplify security audits.
- After the actions complete for adding a user to a model with role (and optionally Selective Access), you can flag that user to no longer update to the planning models
There are 2 downloadable models related to this article.
- The UAM Starter Model has all the core functionality of User Access Management.
- The UAM Starter Planning Sample is the planning model that will be updated with the latest User access information and is also the source for the Selective Access list items that the UAM Starter model uses.
Got feedback on this content? Let us know in the comments below.
Contributing authors: Paul Rosal, Becca Robertson, and **** Jacoby.
Comments
-
While this is great, I'm curious what the solution is for removing a user completely from the spoke models. You eventually import into the native User Settings as a "No Access" role, but when would you delete the user from the model entirely? Trying to keep the Users Settings tab clean is important for me because we have many security items dimensioned by Users, and inactive Users will expand our model size.
1
