Skip to Content
avatar image
Former Member

PPM Security Advice Needed

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

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • Best Answer
    avatar image
    Former Member
    Nov 12, 2013 at 08:10 PM

    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

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      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

  • avatar image
    Former Member
    Nov 13, 2013 at 10:10 PM

    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

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      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.