Authorization Model
Overview
The SAP LeanIX out-of-the-box Authorization model (part of the overall Meta-Model) includes three default roles, VIEWER, MEMBER, and ADMIN. In general, these roles govern access to read (view), create (add), update (edit), and delete information at the Fact Sheet TYPE level. This "information" includes but is not limited to attributes, relations, and tags. This means that the Authorization Model is set and defined for the entire Fact Sheet TYPES, for example, IT Component. There are also some capabilities surrounding Import, Export, Saved Searches, and more.
Please see the Meta-Model for basic information on what a Fact Sheet TYPE is and what is the SAP LeanIX Meta-Model.
You can request that these settings be different per role, VIEWER, MEMBER, and or ADMIN. In addition, you can also request that new roles be added to the authorization model; they would exist in addition to the standard roles.
The ability to configure the Authorization model is contingent upon the SAP LeanIX package that you have. As such, please discuss any authorization model changes that you are considering with your CSM, and they can inform you if your package covers authorization model changes. This document is not meant to be exhaustive in nature, as such, having a conversation with your CSM regarding your use case, especially if it's not covered in this document, could be very useful.
Virtual Workspaces
If your organization is looking to control access at the level of individual Fact Sheets. Your Use Case may be able to be accommodated by Virtual Workspaces. The standard Authorization model cannot control access to individual Fact Sheets.
Requirement
New Authorization Model roles can only be created and utilized when your organization has your Identity Provider configured as External IDP.
Any customer can request that the out-of-the-Box roles be updated (no new roles being created), this does not require a particular IP configuration (assuming that your package allows Authorization model changes).
Terminology
Please see the chart below for helpful terminology:
| Terminology | Definition |
|---|---|
| read | To be able to "see", to make visible. For example, this can be defined for a particular attribute and or relation. |
| create | To be able to associate a response to an attribute, relation, etc that is "null"/empty/not filled out. |
| delete | To be able to remove/delete information that has been entered AND SAVED against a particular Fact Sheet within a particular attribute, relation, etc. Such as a particular relation, e.g. the Data Objects relation on the Application Fact Sheet type. |
| update | To be able to edit information that is already existing. For example, the Description of a Fact Sheet reads, "A new version is coming out in 2022". If a user is assigned to an authorization role that has access to update this attribute, they would be able to CHANGE the answer to anything else they wish, such as "A new version is coming out in 2024" |
Fact Sheet Attributes
The most commonly requested authorization model configuration changes pertain to controlling read (view), create (add), update (edit), and delete access on attributes. As previously explained, for the most part, the Authorization Model works on the level of Fact Sheet types. If you need clarification on what an attribute or relation is, please see the Meta-Model.
For each attribute and or "relation" on a Fact Sheet type, it is possible to define whether a role has a view, edit, and or delete access to it. These properties can be combined into several combinations, that is, as long as it is logical. For example, you would not set the Description attribute to be write(edit) access, but NOT read(access) for the MEMBER role or any role. After all, a user cannot edit what they cannot see.
In the example below, the Description attribute has been set to be read-only (view only) for any user assigned to the Member role. You can see that the attribute is visible but greyed out, which indicates to the user that they do not have access to edit this attribute.
The same can be done for any attribute and or relation, whether it's an out-of-the-box attribute such as a description or a custom attribute (an attribute that was created by the customer using self-configuration).
The same logic applies when setting an attribute to write(edit), delete, and or update properties. You can see in the screenshot above that any attribute that is available to write (edit) has a textbox that is white instead of grey.
Below is an example where create (add) was restricted for Members on the Application Fact Sheet type, Application to IT Component relation. You can see that there is a lock symbol within that subsection indicating to the user that they cannot "add"/create a new relation.
Common Use Case: Hide Costs
A common use case is making cost and or other financial information hidden from specific authorization roles. The "Total Annual Cost" is an out-of-the-box attribute that can be found in several relations, including the Application to IT Component relation. This can be done by removing "read" (view) access for that particular attribute and or relation.
Below you can see that the Total Annual Cost is not visible to the user who signed in under the MEMBER authorization role:
Fact Sheet Type Level
Entire Fact Sheet types can be set to be read, created, updated, and or deleted per role. In the example below, take a look at the upper left-hand side. Notice that the Provider Fact Sheet type is no longer visible to any users assigned to the Member role. This was done by removing read (view) access.
Similarly, entire Fact Sheet types can be set to be read-only (view) by specific roles. This means that those roles would only be able to view the information for any Fact Sheets under that particular Fact Sheet TYPE, but they would not be able to delete, update (edit), nor create any information. This is helpful for Fact Sheet types that represent fixed models or taxonomies like Business Capabilities and or Tech Category.
In addition, the Export, Import, and Inline Edit functionality can also be restricted. In the below example, Import and Table Edit have been restricted for MEMBERs for the Application Fact Sheet Type. As you can see, the user does NOT have access to the Import functionality, which would normally be in the highlighted area on the right-hand side.
Please see below, and notice that the Import button is not available for the Application Fact Sheet type.
Below is an example where the MEMBER role has been restricted from "Archiving" any Application Fact Sheets:
Subscription Type Check
Any attribute or relation can have a "subscription type check" against it. If you are not familiar with Subscription Types, please see the Manage Subscription Roles.
A subscription type check allows you to define read, create, delete, and or update access based on that user's subscription type for that particular Fact Sheet TYPE. The actual check occurs at the Fact Sheet level, this is because subscriptions are assigned to the necessary users, on each Fact Sheet, via the Subscriptions tab of that Fact Sheet.
In the example below the audimex Fact Sheet has one subscription type assigned, which is the subscription type of Responsible. Please take note that it is not possible to complete a check by "Application Portfolio Owner". Application Portfolio Owner is the Subscription Role, and the type is "Responsible".
Saved Searches
Saved Searches access can also be controlled, but these changes apply to All Fact Sheet types. It is not possible to define access differently for Saved Searches by Fact Sheet Type. The same options previously described are available read (view), create (add), update (edit), and delete.
In the example below, as a Member I have read, create, update, and delete access. This Saved Search is named "No responsible set". You can see in the upper right-hand corner, along with the grey box, that I have access to Save As (UPDATE) and Save (CREATE)
Saved Searches Permission Settings
The Authorization model will respect the specific Saved Search settings, defined at the time that the Saved Search is created and Saved. For example if "User B", creates a search and sets it so that only they have access to edit it. I as "User A", cannot update that Saved Search even if the role I have has access to update Saved Searches.
Granular Access
In addition, "change-owner", and "manage predefined" can be set. Change Owner is referring to the "Change Owner" button available within "Manage Searches". In the default Authorization model, the only role that has access to these two properties is ADMIN.
General Categories:
| Type | Details |
|---|---|
| Published | |
| Private | |
| Shared | |
| System | This is referring to predefined Saved Searches, that all users have set by default. |
Saved Searches can be defined at another level of granularity:
- Published[own]
- Private[own]
- Shared[own]
In the above examples, the functionality is restricted to the users "own" those Saved Searches. Meaning the searches that they themselves created.
Summary of Functionality
The Authorization Model allows for the configuration of many different combinations of access both within Fact Sheet types, and with other Fact Sheet related functionality such as Saved Searches.
Please see the tables in the following sections for a capabilities summary of the Authorization model.
Please refer back to the table available in the "Terminology" section, which provides details on the specific access properties that can be defined, they are read, create, update, and delete.
Routines
The table below focuses on executable programs, such as the Export routine, that you as a user can trigger, as opposed to fields/attributes within a Fact Sheet. As such, the normal CRUD operations (create, read, update, and delete) don't quite apply here. In general, if a user can see a routine, then it follows that they can run/execute that routine.
| Functionality/Area of Interest | Is it possible to configure | Details/Example |
|---|---|---|
| Import | Yes | This is can be set by Fact Sheet TYPE. Meaning that this can be set to be viewable and usable on all Fact Sheet Types except IT Component (as an example). |
| Export | Yes | This is can be set by Fact Sheet TYPE. Meaning that this can be set to be viewable and usable on all Fact Sheet Types except IT Component (as an example). |
| Inline Edit | Yes | Please see the Inline Editing, for information on what Inline edit is. Please note that Inline Edit DOES respect the Authorization model. For example, the MEMBER role is only able to read but Not update or create, the attribute Description for Application Fact Sheet types. In addition, the MEMBER role does have access to Inline Edit. This means that they will be able to click on Inline Edit and utilize it, but they will only be able to "read" the Description for Application Fact Sheet but not update, delete, or create. This can be set by Fact Sheet TYPE. For example, for a specific role(s) this could be set to be viewable and usable on all Fact Sheet Types except Provider. |
| Archive | Yes | Please see the Find Fact Sheets in the Inventory, for information on what Archiving is. This is set per Fact Sheet TYPE. |
| Saved Searches (previously named bookmarks) | Yes | Example, "set the role NONMANAGER to be able to CREATE Saved Searches, but NOT update (edit)". This would apply to any and all Saved Searches for any user assigned to the NONMANAGER role. However, it does respect, the specific settings defined on the Saved Search. For example I can create a Saved Search and set it so that only I have access to edit it, this is defined on the Saved Search itself when I create and save it. The Authorization model will respect this. In addition, "change-owner", and "manage predefined". Are also available as properties that can be set. In the default Authorization model, the only role that has access to these two properties is ADMIN. Saved Searches can be defined at a more granular level: General Categories: Published, Shared, System(this is referring to predefined searches) Further granularity: Published[own], Shared[own] |
| Invite | Yes, but not via the Authorization model | Please reach out to support at SAP LeanIX Support or reach out to your CSM for more details. |
| Cloning | No | For more information on Fact Sheet cloning |
| Printing | No |
Fact Sheet Specific
| Functionality/Area of Interest | Is it possible to configure | Details/Example | Create | Read | Update | Delete |
|---|---|---|---|---|---|---|
| Fact Sheet Types | Yes | This is referring to entire Fact Sheet Types e.g Application, IT Component etc. Example set the "custom" role MANAGER to only READ (view) Application Fact Sheet types. This means that this role would not be able to create, update, or delete any Application Fact Sheets. | X | X | X | X |
| Fact Sheets (as in individual Fact Sheets such as Audimex) | No | No, access to individual Fact Sheets cannot be controlled via the Authorization model. One example of such a request is : can the Fact Sheet Audimex be completely hidden for MEMBERS. The answer is no. However, this functionality is available within Virtual Workspaces. | ||||
| Tags (referring to associating tags to individual Fact Sheets) | Yes | This is not referring to creating Tags in the Administration area, but rather associating tags to Fact Sheets.* In addition, this is referring to all tags. It is not possible to define a particular set of tags that the role(s) should have access to. | X | X | ||
| Tag Groups | No | Example, set user NONMANAGER to only be able to see, the tag group "Cloud". This is not possible. You might find it beneficial to remove some Tag Groups and instead set them as attributes. The benefit to this is that attributes can be set to create, read, update and or delete. This is a possibility that might be optimal depending on your Use Case. As such please contact your CSM in order to discuss this. | ||||
| Attributes (also called fields) | Yes | Examples of out-of-the-box attributes are Description, Alias, Release, and Name. Including attributes that are within relations such as Total Annual Cost. Attributes also includes any customer defined attributes. Depending on your SAP LeanIX package, you might have the ability via Self-Configuration or via SAP LeanIX Support to create attributes that do not exist in the standard Meta-Model. If you have Virtual Workspaces, the "ACE" read and write can also be controlled in the same way as all other attributes. | X | X | X | X |
| Relations | Yes | X | X | X | X | |
| Attributes that exist within a Relation | Yes | For example, the standard Application to IT Component relation, includes a Total Annual Cost Attribute. This could be set to be READ only for the MEMBER role. | X | X | X | X |
| Quality Seal | Yes | It is possible to define for the property "update" only, this is due to the nature of the functionality. For more information on the Quality Seal, please see the Increase your Data Quality | X | |||
| Fact Sheet Tabs | No |
Administration Area Functionality
The entire "Administration" area is hardcoded to only be accessible to the ADMIN role. It is not possible for any other role to have access to the Administration area. Furthermore, it is not possible to define specific access to the Administration area even for the ADMIN role. Any user with this role will automatically have access to everything under the Administration area.
Please note that all users have access to Profile, Password, and Notifications. These three options are available under "My Settings".
Dashboards
At this time there aren't specific settings within the Authorization model that determine access to Dashboards. However, when users create Dashboards, they can define some access settings for the particular Dashboard that they are creating. For more information on Dashboards please see the Dashboard Modelling.
Dashboards and the VIEWER role
At this time, all roles are able to create Public Dashboards even those with the role of VIEWER.
Updated 3 months ago