cancel
Showing results for 
Search instead for 
Did you mean: 

PPM Security Advice Needed

Former Member
0 Kudos

Hi PPM Security Experts,

I was hoping you can provide some guidance with an issue I'm having.

Here's my situation:

> Business requirement is to have the following roles:

- Create/change portfolio initiatives, items & reviews (segregated into 3 roles for each portfolio object)

- Display portfolio initiatives & items (all initiatives, items & reviews - again, segregated into 3 roles for each portfolio object).

> Current solution:

- Have built the create/change roles with auth. object ACO_SUPER (admin/write/read)

- Have built the display roles with auth. object ACO_SUPER (read)

> Problem

- I am finding that my back-end PFCG roles are overridden by the front end 'miscellaneous' authorizations tab when users assign permissions to portfolio objects manually (i.e. assigning admin access to a portfolio initiative to a user, even though that same user only has display access in his/her back-end roles).

Based on some discussions that I've read, it has been suggested not using the ACO_SUPER object. Therefore, I am wondering what object(s) I can use instead to meet the business requirement above? Can someone perhaps provide me with an example or two of I can achieve this? Or do you guys think that the usage of ACO_SUPER would meet my requirements?

Your help would be greatly appreciated! Even some minor guidance would be great!

Warm regards,

Jerry

Accepted Solutions (1)

Accepted Solutions (1)

former_member209919
Active Contributor
0 Kudos

Hi Jerry,

I am not an authorization expert but I will try to share you my ideas.

-  authorization 1 ( admin/write/read)

-  Authorization2 ( read)

Yes, you can get this with ACO_SUPER object.

If your problem is these authorizations can be overwritten by the ACL author you can hide the tab/ section ( miscellaneus/ author) for all objects ( portfolio, buckets, initiatives, items.. Etc)

Not sure if you can prevent that a user with admin modify a bucket but I think this authorization model is so simple and it is valid.

Other option is not use ACO_SUPER and create roles

1) roleA

2) role B

You assign Role A with write + create author at portfolio or bucket level

You assign Role B with display author at portfolio or bucket level

( in any case you should hide tab authorizations in item and initiative) this is because user that creates it has admin author in the object and can change the rest of the authorizations.)

Then assign role A to users that can create/ modify initiatives and items and role B to the rest.

With this model you can control at which bucket/ initiatives/ items the use has access ( imagine you have bucket USA and bucket CANADA and you assign role A only to USA) users will be able to edit only objects in bucket USA ---> this is the advantage to not use ACO_SUPER but it seems that you don't need this.

In any case if you decide use ACO_USER option and then change your authorization model I think it would be simple.

You also comments:

You need 3 roles one that can display initiatives, another items and another reviews.

Not sure how easy is this but i can give you can have something similar: when you enter in PPM newtweaver you will see the options : portfolio structure, initiatives, items, reviews, what-if scenarios etc.

These options are controlled with roles ( menu of the role) then you can biult 3 roles

1-role menu has initiatives

2-role menu has items

3-role menu has reviews

with this option user with role menu 2 and 3 will have dashboards for items and for reviews ( but not for initiatives) ,,,,, this not means that he has not author to display initiatives.

Not sure if this helps you and if everithing I have wrote it is clear and correct. You can check it and let me know if you need something else

Regards,

Clara

Former Member
0 Kudos

Hi Clara,

Given that the requirement is access to ALL portfolio, buckets, initiatives, items, etc. I have decided to use ACO_SUPER. Any other risks in using this authorization that you are aware of?

I will suggest that the Authorizations tab is hidden to prevent mis-use of this feature.

With respect to the roles, I have already done what you have suggested:

1-role menu has initiatives

2-role menu has items

3-role menu has reviews

I believe that I have built my roles correctly, but was hesitant with the ACO_SUPER object and that's why I figured I'd share my concern.

Thanks very much for your help! It was very helpful.

Warm regards,

Jerry

former_member209919
Active Contributor
0 Kudos

Hi Jerry,

I don't see a risk with your roles, with them some users will be admin of all  current and future objects and other users will display all information.

If you are aware of this and it is your requirement you can build these roles.

Usually it is not recommended because other portfolios, buckets for different business can be included in PPM and with your model it is not easy manage these author, but only for this reason.

In any case, you can start with your roles and if you detect some problems or an authority hole you can recheck the roles.

Regards

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Jerry,

Here's my opinion on this topic based on what has worked for me in past projects.

I would advise you to not assign ACO_SUPER to general users. This auth object should only be reserved for admins who want to by-pass ACL authorizations.

SAP provides the following template roles which you should use as a basis for creating your custom roles.

SAP_XRPM_USER

SAP_CPR_USER

These provide the minimum needed authorization in order to login to PPM. Once logged in, what a user can see and do is controlled by ACL authorizations. So for the purpose of this explanation lets assume that you created ZPPM_USER which has all authorizations contained in SAP_XRPM_USER and SAP_CPR_USER. You can go to the ACL of the portfolio and assign "read" authorization to ZPPM_USER. ACL authorization will then be inherited to the buckets and items/initiatives within the buckets. This will address your requirement to allow everybody read access.

In order to provide create access in addition to "read" in the ACL, you can also check the "create" box. Now user A with only ZPPM_USER assigned will be able to create objects and will have admin access to his/her objects and read access to others.

Next, how do you control access to the different object types such as buckets, items and initiatives. There are no specific authoization objects or ACL's which specifically address these object types. The way I control access by object type is by limiting access to the various dashboards, based on the idea that if you can't see it you can't click on it. If you are using the Enterprise Portal you will need to define portal roles that specify which dashboards the users have access. If you are using NWBC you will have define navigation roles based SAP_BPR_PPM. So far example if you want users to not create initiatives, you simply a define a navigation role which does not contain the initiative dashboard.

Therefore, at a minimum a user should have ZPPM_USER with ACL "read" and "create" at the portfolio level + navigation roles (either portal or NWBC) which define the different dashboards they can access.

In addition, SAP provides other "template" roles that you may also need. Please refer to the security guide for more details --> http://service.sap.com/~sapidb/011000358700001365792010E

I do realize this may sound rather complex, but once you understand the concept of using traditional SAP auth objects along with ACL it makes things a lot simpler and your back-end roles less complex. Feel free to ask if any of the above is not clear.

Hope this helps,

Lashan

Former Member
0 Kudos

Hi Lashan,

Thanks for your response. It was very detailed and useful.

However, I do not think your solution is entirely applicable to my current situation (although your solution is completely valid) for the following reasons. Feel free to correct me if I'm wrong.

- If I do not use the ACO_SUPER object, as you have suggested, then I will have to assign read functionality via the front-end authorizations tab to all users at the Portfolio level (and this will be inherited across buckets, items, etc. in that same portfolio). However, performing this activity is a challenge because of the user mass and because users are constantly being provisioned in the system. Ideally, I'd like to only assign the PFCG roles and not perform any ACL activities at all.

- Providing read/write access to all users at the Portfolio level will only grant them read/write access to that specific portfolio. When/if new Portfolios are created, then all users will need to be given read/write access to the new Portfolios, which again, would be a very manual and tedious process.

- As a sub-point to the point above, this is also true for Portfolio admins. The requirement is that all Portfolio Admins should have access to read/write ALL portfolios (and all of the objects contained within them). As such, this access must be granted to all Portfolios via ACL,and in my opinion, this can be more easily achieved via the ACO_SUPER object.

- Lastly, given that there is no requirement to use ACL (yet), I'd like to avoid this if possible. Ideally, I'd like to control everything via back-end PFCG roles.

With that said, are you able to outline for me the risks associated with using the ACO_SUPER object? What drawbacks or disadvantages are there in assigning this object (restricted to admin/write/read accordingly, of course)? Is there a specific reason, or reasons, as to why you would not recommend it?

Your input would definitely be helpful. Thanks again for your previous response!

Warm regards,

Jerry

Former Member
0 Kudos

Hi Jerry,

Let me try to address your questions.

  • In the ACL, you will assign authorization by role, not the individual user. If you go the "miscellaneous" tab and "user roles" subtab you can assign a PFCG role and anybody assigned to that role will get the ACL authorization. You do not assign authorization individually since as you have pointed out its going to create a maintenance nightmare.

  • Regarding the portfolio, I don't know the specifics of your business so I am going to make some generalizations. The portfolio object is extremely high level, you ideally should not be creating new portfolios on a regular (or even not so regular) basis. In fact, within same company you would typically have multiple portfolios if you want to completely segregate your portfolio of projects, for example 1 portfolio to manage NPD type projects and another for IT project or 2 portfolios to manage completely different business units.

  • For portfolio admins, you can assign them a role which contains ACO_SUPER to avoid the need to give them ACL authorizations. However, the portfolio admins I presume would represent only a very small % of your users base.

  • Not using ACL - ACL's used correctly makes your security setup stronger and much easier to manage and more flexible, so personally I have never considered not using ACL's. PPM (even if you go back to the old days of xRPM and cProjects) was designed around the idea of using ACL's in conjunction with traditional SAP roles for managing authorizations. Other modules such as DMS and PLM 7.01 web apps have since adopted this concept. With setup that I had previously outlined, the general users rarely have a need to modify the ACL's since the system handles authorizations automatically. Exceptions are for example, if I want restrict access to my project only to team members, then I need to go into the ACL and restrict access. You should also look at DFM for synchronizing authorizations between portfolio items and projects.

  • The risk associated with ACO_SUPER is that it can override ACL's authorizations and provides more access than needed. Of course this point is moot if you are not using ACL's.

Again I am not familiar with your business and any constraints, but I have found the above type of security setup works well for all of the projects that I have implemented which have been pretty diverse.

Regards,

Lashan

Former Member
0 Kudos

Hi Lashan,

I have a situation where I need to overrule that creators of Items and (autmoatically) Projects have "Admin" rights and change this right to "Read". I thought I could simply do this from portfolio level, but this is first of all restricted to the Bucket and Item objects and does not affect the Projects. Second of all the "admin" rights a user gets when creating the Item and Project overrules what is inherited to them from parent objects.

So, I need to be able to change the creators rights from "admin" to "Read" and preferably in a simple way.

A thought I had was, that if this can be done with inheritance from Portfolio level, then I might be able to set up DFM between Item and Project to let the "admin" right change in the Project Definition to "read" as well?

Hope you can help,

Br,

Morten.