cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

RPM Portfolio 5.0 Security Issue

0 Likes
454

I have set security up at the portfolio level by role so when the user is assign the PFCG role in the backend they get access accordingly.  We did this so that we would not have to assign individual users.  This works well but we have run into an issue with a few users getting access to additional portfolios which the role is not linked with. 

Example:  Portfolio A has role AA - set with Read/Write/Admin, role AB set with Read/Write and role AC set with Read only.   Portfolio B has role BA, BB and BC with same access levels.

If a user is assigned role AB which is linked only to Portfolio A when they click on switch portfolio option they can see Portfolio B and also have the ability to make changes if that role level is assigned.  This does not happen for all users who have Portfolio A assigned.  I have about 7 portfolios in our system with this same set up and not all portfolios are visible to users and there does not appear to be any consistency on which ones appear to which users.

The PFCG roles are built based on Portfolio naming convention.  We have a series of portfolio for what we call divisional access those PFCG roles are all based off a single parent so they have the same objects/activities included.

I am at a loss as to why this door opens for some users and not for all.  Any suggestions on how to go about trace, log, etc. to find the link would be greatly appreciated. 

Also looking for a way to set the default portfolio for users by role or other setting?

Thanks

Kathy Brethouwer

Sr. Systems Analysis - Security

Molex Inc.

Accepted Solutions (1)

Accepted Solutions (1)

former_member209919
Active Contributor
0 Likes

Hi Kathy,

If the role has assigned this authorization object ACO_SUPER, the user that has this role will see all porfolios. Check if your roles have this object and if they have it, remove it.

If your roles don't have this authorization object..then you have to review where are these roles / users assigned. If a user can select portfolio B this is because he or his role is assigned to the portfolio, bucker, initiative , item or decision point of this portfolio.. You need to find where... Let me know if you need help to find where users/roles are a ssigned to the objects.

Regards,

Sara

0 Likes

Thanks Sara that did the trick.  I had the ACO_SUPER in one role opening the door.  The role somehow got disconnected from the parent and was out of sync.

Former Member
0 Likes

Hi,

I feel its all about roles. if you are giving access to portfolio based on roles assigned at portfolio side there some conflict in users and their assigned roles. The users who are having some level of access in one role to particular portfolio whereas in other roles they are restricted with different level of authorization, then the problem may arise.

I feel user need not to have ACO_SUPER for portfolio read / write / admin / create access.

Regards,

Pramod

0 Likes

The ACO_SUPER did the trick but I also found that under the miscellaneous tab the authorization option is displayed and allows users to add users/roles manually which then bypasses our controls at the roles level.  I would like to hide the "Authorizations" option under the "Miscellaneous" tab in the portfolio item for everyone unless they have the ACO_SUPER object for ADMIN.  Is this possible?

I would go with the ACL option of ADMIN except if the user create the item they are automatically made the admin of that item so that will not work.  I need this closed off except for myself and the application lead person.

Any help would be appreciated.

Thanks Kathy

Former Member
0 Likes

Hi Kathy,

I believe, you should give ACO_SUPER access to real super users who will work as administrators. As I mentioned try to follow the authorizations from Miscellaneous tab and control authorizations of users from there.

Its not advisable to give ACO_SUPER authorization to users. You may need to do some rework but I feel it will solve your future problems.

Regards,

Pramod

0 Likes

I believe you mis-understood my reply. I fixed the originating issue and it is resolved however during the investigation based on above feedback I found the part of the cause is that item owners were manually adding users/roles to their items.  I want to block them from being able to do that.

I only give ACO_SUPER to real super users and it is only those users who I want to be able to view or use the "Authorizations" option under the "Miscellaneous" tab of the Portfolio Item.  So I want to hide this option to all users unless they are a SUPER USER with ACO_SUPER access for admin.  There are currently only 2 of us with this level of access. 

Please advise if further clarification is required here.

former_member209919
Active Contributor
0 Likes

Hi Kathy,

I have the same requirement.. If you create the item you  are admin and you can manage all authorizations in the item . This is standard and I think it cannot be solved by standard, admin user can do everything even delete the item.

Please if you find a solution or workaround share in the forum!

Thanks,

Sara

Answers (1)

Answers (1)

schneidertho
Product and Topic Expert
Product and Topic Expert
0 Likes

Hi Kathy,

could it be that the users seeing Portfolio B (even though they do not have the corresponding B role) are assigned to an item in B individually? I have not other immediate idea...

Best regards

Thorsten