- SAP Managed Tags:
A few months ago, I was presented with a problem related to PPM security. Being the first time to troubleshoot this topic, I found it interesting to share this detail for all those that, like me, struggled to understand the variables involved. I would like to present this example model, as models are useful for better understanding. The model presents a portfolio with some objects and the design will provide correct access based on ACL functionality and standard roles assignment.
Ready? Here we go…
Portfolio: Rainbow Wonderland
Main areas: Pink Unicorn, Green Unicorn and Blue Pegasus
Each Area is divided in 2 main components:
The portfolio structure looks like this:
Super-secret Magic element components
Public Elements
How should roles be defined and assigned using the ACL concept?
Defining roles for end-users
General information on the PPM security can be found here:
Security Guide for SAP Portfolio and Project and also Quick for Implementing PPM
Standard existing roles will be utilized in this example:
SAP_XRPM_USER - General user in Portfolio Management. All users should be assigned this role. Has general authorizations to use Portfolio Management, but no specific object access. This access must be assigned to the user via ACLs.
SAP_XPRM_ADMINISTRATOR - should be assigned to Portfolio Administrators with the authorization to, for example, create portfolios and maintain all portfolio objects.
SAP_CPR_USER - Use Project Management, but no authorization to perform any activities in a particular project. To do this users need project-specific authorizations, which can be distributed either directly via ACLs or through their assignment to a role. This role must be included in every Project Management composite role.
If users access through Fiori:
Back-end roles need to have the information related to Fiori tiles selected. This is based on the SAP Fiori Tile Catalog. Refer to the material below:
How to Create and Generate Backend Security Authorizations for SAP Fiori 2.0
Then, based on the technical information of the Fiori tile, we would include more roles as well:
Back-end Role: SAP_PPM_PFMMITPR_CHG_APP
A set of shell roles were created to include groups of magical creatures under the same object and color. Here is the design of “Shell” roles applied to Rainbow Wonderland Portfolio.
The roles are empty inside and are only created for the purpose of access restriction on this example:
It is important to define the correct granularity to achieve the correct restriction. In this example granularity is defined by color and activity type of creatures.
Wizards – Z-WIZ
Magical creatures – Operator Z-MCO / Constructor Z-MCC / Project Manager Z-MCP
Note: additional security access need to be complemented with these standard roles. Discuss with your security colleagues.
It is important not to provide ACO_SUPER object to any of the roles, as this will prevent user restriction PPM objects, overwriting the ACL restriction. This sneaky demon is one of the reason why restriction of access will not work in your design.
User role assignment example:
Green Wizard user: Fred
Z-WIZ – This role is to provide general access to portfolio and Project Management
Z-WG – This role will be used to provide access to Buckets and items of the portfolio
When a user creates an element, it becomes the person with Admin access in it. If Fred created a portfolio item, his user id will be populated as admin authorization automatically.
The graphic of Rainbow Wonderland would look like this:
Example of Inheritance from Bucket to item here:
Information inside shell role Green Wizard, it will display all users assigned to the role
Information of the concept is here Super User concept
Now, let’s say one of the Green Wizards goes on vacation while working on a secret item, if he forgets to assign a new Green Wizard to the portfolio item, nobody will be able to access the Cproject structure. To avoid this problem we will configure the Superuser concept like this:
We assign the role of the Green Wizards to the project type Z-SPG. The type is only utilized when creating a project on the super secret elements (Green) area.
When creating the Cproject by any Green Wizard, this will be the Cproject Authorizations view on the User roles tab:
This will solve the issue of the forgetful green wizard.
Easy! End users are ready to access PPM objects.
Final notes:
I hope you have found this model useful to correctly define access to PPM objects.
Please, share your comments and difficulties that you faced on your designs.
Enjoy PPM ACLs!
Ready? Here we go…
Some context on the example to start with
Portfolio: Rainbow Wonderland
Main areas: Pink Unicorn, Green Unicorn and Blue Pegasus
Each Area is divided in 2 main components:
- Super-secret magic elements
- Public Magic elements, below the magic elements more buckets representing different magic elements.
The portfolio structure looks like this:
Rules for portfolio Buckets
- Magic creatures in the Unicorn areas are administrators on their own color and have read access on each other’s objects. They are not allowed to see what’s going on inside the Blue Pegasus Area.
- Blue Pegasus magic creatures are not allowed to see the any of the unicorn areas.
- Whatever happens on the Super-secret magic element areas, cannot be seen by anyone else. Only creatures assigned to that particular area can see what’s going on there.
Rules for Portfolio items and Cprojects
Super-secret Magic element components
- Portfolio items indicating the Super-secret magic element being developed
- Cproject Structures under the mentioned portfolio item
- Only one role will be able to create new portfolio items here and I will call it Wizard. Wizards can to include more magic creatures in the Super-secret magic element if required.
Public Elements
- Portfolio items for Operating Magic Elements – To be managed by Magic Creature Operator
- Portfolio item for Magic Elements under construction – To be managed by Magic Creature Constructor.
- Magic creature Project manager will have access to the Cprojects linked to the Magic Element under construction, Magic Creature Constructor will provide it access.
Magical Problem
How should roles be defined and assigned using the ACL concept?
Defining roles for end-users
General information on the PPM security can be found here:
Security Guide for SAP Portfolio and Project and also Quick for Implementing PPM
Standard existing roles will be utilized in this example:
SAP_XRPM_USER - General user in Portfolio Management. All users should be assigned this role. Has general authorizations to use Portfolio Management, but no specific object access. This access must be assigned to the user via ACLs.
SAP_XPRM_ADMINISTRATOR - should be assigned to Portfolio Administrators with the authorization to, for example, create portfolios and maintain all portfolio objects.
SAP_CPR_USER - Use Project Management, but no authorization to perform any activities in a particular project. To do this users need project-specific authorizations, which can be distributed either directly via ACLs or through their assignment to a role. This role must be included in every Project Management composite role.
If users access through Fiori:
Back-end roles need to have the information related to Fiori tiles selected. This is based on the SAP Fiori Tile Catalog. Refer to the material below:
How to Create and Generate Backend Security Authorizations for SAP Fiori 2.0
Then, based on the technical information of the Fiori tile, we would include more roles as well:
Back-end Role: SAP_PPM_PFMMITPR_CHG_APP
The idea of the “Shell” single roles
A set of shell roles were created to include groups of magical creatures under the same object and color. Here is the design of “Shell” roles applied to Rainbow Wonderland Portfolio.
The roles are empty inside and are only created for the purpose of access restriction on this example:
- Wizards - Z-WG Green/ Z-WB Blue / Z-WP Pink
- Magic Creature Operator – ZMCOG Green / Z-MCOB Blue / Z-MCOP Pink
- Magic Creator Constructor – Z-MCCG Green / Z-MCCB Blue / Z-MCCP Pink
- Magic Creature Project Manager – Z-MCPMG Green / Z-MCPMB Blue / Z-MCPMP Pink
It is important to define the correct granularity to achieve the correct restriction. In this example granularity is defined by color and activity type of creatures.
Composite roles Back-end
Wizards – Z-WIZ
- SAP_XPRM_ADMINISTRATOR
- SAP_CPR_USER
Magical creatures – Operator Z-MCO / Constructor Z-MCC / Project Manager Z-MCP
- SAP_XRPM_USER
- SAP_CPR_USER
Note: additional security access need to be complemented with these standard roles. Discuss with your security colleagues.
Be aware Demon ACO_SUPER
It is important not to provide ACO_SUPER object to any of the roles, as this will prevent user restriction PPM objects, overwriting the ACL restriction. This sneaky demon is one of the reason why restriction of access will not work in your design.
User role assignment example:
Green Wizard user: Fred
Z-WIZ – This role is to provide general access to portfolio and Project Management
Z-WG – This role will be used to provide access to Buckets and items of the portfolio
Inheritance is important, so let’s use it
When a user creates an element, it becomes the person with Admin access in it. If Fred created a portfolio item, his user id will be populated as admin authorization automatically.
- Inheritance rules:
- Bucket -> Bucket
- Bucket -> Item
The graphic of Rainbow Wonderland would look like this:
- Operators and Constructors are administrators on their own colour for Buckets and read access to other sections.
- Inheritance from Bucket to Cprojects does not work, only roles or users assigned directly to portfolio items will be inherited to Cprojects, (Note 1249825). Then, Project Managers roles have to be assigned manually to the item.
- Wizards are assigned to their own portfolio Buckets by color. No other roles will be assigned at the level of Super Secret Magic Elements.
- If Fred wants to have access to another portfolio item not created by him, he will be able through the inheritance of roles from Bucket Super Secret Creatures (Green)
Example of Inheritance from Bucket to item here:
Information inside shell role Green Wizard, it will display all users assigned to the role
New Super User Concept in Project Management
Information of the concept is here Super User concept
Now, let’s say one of the Green Wizards goes on vacation while working on a secret item, if he forgets to assign a new Green Wizard to the portfolio item, nobody will be able to access the Cproject structure. To avoid this problem we will configure the Superuser concept like this:
We assign the role of the Green Wizards to the project type Z-SPG. The type is only utilized when creating a project on the super secret elements (Green) area.
When creating the Cproject by any Green Wizard, this will be the Cproject Authorizations view on the User roles tab:
This will solve the issue of the forgetful green wizard.
Easy! End users are ready to access PPM objects.
Final notes:
- If you would like to transfer inherited authorizations from Portfolio items to Cprojects automatically, implement BADI BAdI INM_OF_SYNC (Note 1249825)
- It is interesting to explore functionality Decision Flow Management related to authorization synchronization to apply to your own design, DFM functionality set up information here -> https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=489217634
I hope you have found this model useful to correctly define access to PPM objects.
Please, share your comments and difficulties that you faced on your designs.
Enjoy PPM ACLs!
8 Comments
