Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

PFCG - Flexibility for entering Values

Former Member
0 Kudos

In the PFCG screen where we input the organization values for role restriction, I suppose the options available are not very flexible. Is there a reason for this? Is there a way in which we could change the layout? Could you suggest an Exit / Enhancement option for the need?

SAP currently provides the option of inserting new rows, which i feel is not very handy. It could be better and more flexible if we had the option to include/exclude single values and range like the laout we have for SE16 (the tabs Selcet Single Values; Select Ranges; Exclude Single values and Exclude ranges)

Any opinions / advice is welcome

regards,

Shekar

1 ACCEPTED SOLUTION

jurjen_heeck
Active Contributor
0 Kudos

I suspect the functionality of the sub-selection screen on SE16 and other reports is not adaptable to this input screen. I do agree that the subscreen for org values in PFCG is difficult to use when you have to add rows.

36 REPLIES 36

jurjen_heeck
Active Contributor
0 Kudos

I suspect the functionality of the sub-selection screen on SE16 and other reports is not adaptable to this input screen. I do agree that the subscreen for org values in PFCG is difficult to use when you have to add rows.

0 Kudos

>

I do agree that the subscreen for org values in PFCG is difficult to use when you have to add rows.

I think there is a theme here. SAP, are you listening

0 Kudos

>

> >

> I do agree that the subscreen for org values in PFCG is difficult to use when you have to add rows.

> I think there is a theme here. SAP, are you listening 😉

yes.

It's on the schedule to be checked (not only the org.level popup, but also the standard 'maintain values'-popup.

b.rgds, Bernhard

0 Kudos

Hi Bernhard,

I am sorry, but i guess i didnt catch the drift.............are you suggesting that what is asked is on SAPs' "To-Do" agenda for future development? Infact, i was planning to post a message to SAP.

One of the underlying quetsions that missed attention was "Are there any Exits or Enhancement spots related to PFCG"

0 Kudos

Hi,

I can only suggest that you open such a message..... But if you quote it as 'missing funcitonality' you might get it back with note #11....

It is on the to-do list already, but requests from customers raise the chance for earlier realization....

Yes there are some exits in PFCG,but they will not be used anymore in future releases...

b.rgds,

Bernhard

0 Kudos

>

> yes.

> It's on the schedule to be checked (not only the org.level popup, but also the standard 'maintain values'-popup.

>

> b.rgds, Bernhard

Thanks Bernhard, that's good ot know.

Cheers

Alex

0 Kudos

While on the "bandwagon"... ... will the same be applied for the SUIM selection screen F4, with S_USER_OBJ/PRO/GRP etc checks?

Cheers,

Julius

0 Kudos

Julius,

Do you think the PFCG - flexibiity question can be added to the "Security Functionality Wishlist-Topics" ?

maybe you could add the SUIM one too

0 Kudos

I had no idea that the wishlist had such a high profile...

It is added.

Cheers,

Julius

0 Kudos

>

> Hi,

> I can only suggest that you open such a message..... But if you quote it as 'missing funcitonality' you might get it back with note #11....

>

> It is on the to-do list already, but requests from customers raise the chance for earlier realization....

>

> Yes there are some exits in PFCG,but they will not be used anymore in future releases...

>

> b.rgds,

> Bernhard

a quick update:

Inspite of Bernhard mentioning that the development activity is on the To-DO list if SAP, i couldnt stop my enthusiastic self and posted a message with SAP and the outcome "NO conclusive answer". They apparently would be incorporating this in the future. But no foreseeable date is given - so i guess we are up against a wall here

so i come back to the learned man, Bernhard ........

Bernhard, I am sure you would be in a better position to make an assessment........Do you see any practical date towards realizing this dream?? 1 year from now? 2 years????........

0 Kudos

Whatever happens, I really hope SAP do not include the option to exclude single values.

I have seen enough to know it will cause some very screwed up security.

0 Kudos

>

> Whatever happens, I really hope SAP do not include the option to exclude single values.

Everone is entitled to have a opinion, isnt it?

> I have seen enough to know it will cause some very screwed up security.

Not the best of language, to say the least......... We all appeciate the general worldly know-how some people have, but i think it woudl also help a few of us if you could share with us what kind of screw-ups you saw?

0 Kudos

>

> >

> > Whatever happens, I really hope SAP do not include the option to exclude single values.

>

> Everone is entitled to have a opinion, isnt it?

>

>

> > I have seen enough to know it will cause some very screwed up security.

>

> Not the best of language, to say the least......... We all appeciate the general worldly know-how some people have, but i think it woudl also help a few of us if you could share with us what kind of screw-ups you saw?

I think screw up accurately describes what would happen.

At the moment I would say that at least 50% of security admins do not populate fields correctly to start with. The security process in SAP is additive and should remain like that. In that vein, to alter the auth concept so that you can add everything except a tiny bit is no different in concept to using SAP_ALL as a base for a role. The principle is fundamentally flawed if you are following the the principle of least privilege.

If people can't use the relatively simple tools which are at their disposal already then making it more complicated is not going to help in my opinion.

I have yet to hear an argument which has convinced me that this would in reality be a retrograde step for security

0 Kudos

> I think screw up accurately describes what would happen.

>

> At the moment I would say that at least 50% of security admins do not populate fields correctly to start with. The security process in SAP is additive and should remain like that. In that vein, to alter the auth concept so that you can add everything except a tiny bit is no different in concept to using SAP_ALL as a base for a role. The principle is fundamentally flawed if you are following the the principle of least privilege.

>

> If people can't use the relatively simple tools which are at their disposal already then making it more complicated is not going to help in my opinion.

>

> I have yet to hear an argument which has convinced me that this would in reality be a retrograde step for security

sometimes it makes me wonder, if we are driven by too much of an opinionated thought process.......

What is this authorization concept you refer to that says that things should only be added and not excluded? Is there some fundamental rule-set that determines this? I think a logical reason should be the prime driving force of any new development and not judgemental views. If a product is developed with only additions and no exclusions, maybe we would use it for sure - but the logic behind not having a exclusion should still be questioned, isnt it?

Can i get your logic of why an exclusion should not be included.........making a comparison with the SAP_ALL for the base for a role is too abstract and not a clear example. I am ok with your suggestion of having only additions and NO exclusions if it is backed by sound logic

Coming to your practical experience and judgement that "50% of Admins screw it up".........hmmmmm....this is a human weakness, we all tend to do it sometime or the other............ the systems features shouldnt be blamed for it is what i would think. Just because we cause accidents, they dont stop making cars - isnt it?

0 Kudos

> What is this authorization concept you refer to that says that things should only be added and not excluded?

This is also what I have learned and maybe it turned into my opinion as well.

SAP security is about allowing things, not denying.

If it weren't, then why do we have to build roles with all objects relevant for the transaction instead of just the ones we want to limit or deny?

One of the faul-ups I already see with ranges in authorizations is that new entities can be created within these ranges so an unknown amount of users will automatically get extra rights. A denial system will have the same loopholes.

Edited by: Jurjen Heeck on Sep 29, 2009 1:36 PM

0 Kudos

>

> > What is this authorization concept you refer to that says that things should only be added and not excluded?

> This is also what I have learned and maybe it turned into my opinion as well.

> SAP security is about allowing things, not denying.

>

> If it weren't, then why do we have to build roles with all objects relevant for the transaction instead of just the ones we want to limit or deny?

My apologies, but i dont know if i have to reflect back on my primary education....but i dont seem to understanding the complex abstract examples everyone cites.

dont tell me that you are an Auditor too

> One of the faul-ups I already see with ranges in authorizations is that new entities can be created within these ranges so an unknown amount of users will automatically get extra rights. A denial system will have the same loopholes.

>

> Edited by: Jurjen Heeck on Sep 29, 2009 1:36 PM

jurjen,

I can partially agree to this , when new entities within the restricted range are created, users would default get the authorizations, True...............but, isnt this something to do with streamlining processes within the work space........rather than saying that we shouldnt have something because others in the project team dont inform us

0 Kudos

>........rather than saying that we shouldnt have something because others in the project team dont inform us

I hate it as much as you do but assuming they do inform us can and will lead to costly mistakes I prefer to stay on the safe side.

0 Kudos

Scuppered by the post max length, here are answers, please hook up to the relevant points

We form opinions though experience and trying out stuff for ourselves. We evaluate new concepts against our experiences, if relevant.

The principle of least privilege is a common theory, typically represented in the implementation of an authorisation/permissions concept which is based on the premise that access is granted, not removed. Ignoring any technical limitations we then see 2 concepts being used and abused.

SAP_ALL analogy highlights the principle perfectly well. When you create an exclusion you are saying you can have everything except xxxxx.

This principle applies from the high level like SAP_ALL to the low level like excluding a field value.

Why do we not recommend removing a transaction from SAP_ALL? Generally because we know that there is likely to be a lot of stuff left in there which is not required. The same principle applies to excluding a field value. Anyone who works in SAP knows that there are always lots of superfluous field values.

As an example, someone asks for all plants except NNNN. Security admin builds a role containing * in Plant with en exclusion of NNNN. In 99% of cases that access would be granted for plant 0001, dummy plants, retired plants etc. Security is often an inherent control over data completeness & accuracy, in this case that control would be broken. The same applies for document types, some auth groups etc.

If we are to use the car analogy, deaths in cars have decreased massively. Why? because cars are far easier to drive and safeguards have been implemented (seat belts, crumple zones, air bags etc).

Flexibility is great but it comes at a price. A concept needs to be able to align with design principles & remain usable. There are lots of additional things I would like to see which you have also raised an interest in. Just not exclusions in my opinion

Edited by: Alex Ayers on Sep 29, 2009 1:33 PM

0 Kudos

Alex,

I know i can continue the discussion with all gusto and enthusiasm, but i SHOULD ADMIT that your explanation was fantastic and i am willing to buy your point.

One of the biggest angst i have in all the posts i have or in the posts i read, is that there is either missing clarity in the question posed or in the answer updated. If we spend time to write a post like what you did now, the number of posts and also the number of pages per post would surely reduce, Wot say?

Just wanted to let you know, that i rewarded points on the reply you gave - more for the clarity of thought and patience than on anything else

I have great respect for you guys and would love to learn a lot of things from you guys..........but.......... I will stand ground until i am convinced on a argument, i think i have a right there isnt it

I am CONVINCED........

0 Kudos

lol, thanks, no need for points but I'm glad we can enjoy some healthy debate on the point

These questions which deal in "shades of grey" are always more fun!

0 Kudos

Alex,

Mentioning the points was more to emphasize on how much your answer is appreciated

Grey is one of my favourte colours

I was just thinking........that it is good that we are not in the wilde west kind of scenario, with guns hanging around the hips.....and face to face......

0 Kudos

>

> I was just thinking........that it is good that we are not in the wilde west kind of scenario, with guns hanging around the hips.....and face to face......

Good point, I think Julius would have taken most of us out by now

0 Kudos

In addition to the principals, there is also a performance consideration:

Currently the authority-check does a fast-check for the authorization object in the user buffer and if found, will then search for the value set for it's fields in the authorizations using the values from the coded statement (millions of them).

The first one which satisfies the check, sets sy-subrc to 0.

Now imagine if the user has the authorization value sets in one role and an exclusion in another.

=> You cannot realisticly sort the order of the checks, so would at the very least double the performance expense.

=> If you declair an exclusion as taking preference, the check would need to evaluate all authorizations (much more than double performance costs) or each authorization field with a new key for it first, and then still perform the current positive check afterwards, each time.

I cannot see that being retro-fitted.

It is much easier to check the authority of the user in such a special case, and if they pass the authority-check then react to the return code by denying access - but I cannot see that finding widespread acceptance either.

More common is to find exclusive solutions by making the functionality completely unintuitive. An example is in the menu of SE16N when deleting change documents. It is dependent on your authorizations, but you are excluded from it even with SAP_ALL. In this case, you actually need to know how to use it - in which case you probably won't...

The suggestion of an import function as with selection screens (possibly with the option to validate the entries) is indeed a great idea and please add it to the wiki. I guess SAP needs to work out the software logistics first and whether anything else is impacted before they can commit to any date or SP level for this.

Cheers,

Julius

0 Kudos

wow..Julius...........mightily impressive and very.... very logical.

I think you should have a look at my other posts too

0 Kudos

Do you think the PFCG - flexibiity question can be added to the "Security Functionality Wishlist-Topics" ?

This wishlist development request has been implemented and released now --> [SAP Note 1599732 - PFCG popup to maintain values supports clipboard pasting|https://service.sap.com/sap/support/notes/1599732].

Note that the solution is compatible from release 7.00 onwards.

Thank you SAP and Bernhard!!

Cheers,

Julius

0 Kudos

Thanks to everyone who participated in the debate and special thanks to Julius for having updated us on this.

By the way i was wondering, if the first thing Julius does every morning is check for SAP notes

on a serious note: Julius, how do you manage to know what's new in town and "hot"

0 Kudos

Someone noticed it who knew that I was interested and then I remembered this discussion and the wiki wishlist it produced.

The thanks should go to SAP!

0 Kudos

you made me feel like a kid who didnt do his bedtime prayer ....so here it goes

Thank You, SAP

0 Kudos

> This wishlist development request has been implemented and released now --> [SAP Note 1599732 - PFCG popup to maintain values supports clipboard pasting|https://service.sap.com/sap/support/notes/1599732].

>

> Note that the solution is compatible from release 7.00 onwards.

>

> Thank you SAP and Bernhard!!

>

> Cheers,

> Julius

One additional feature:

The upload function has been delivered also for the Menu-tab of PFCG:

[SAP Note 1630328 |https://service.sap.com/sap/support/notes/1630328]

b.rgds, Bernhard

0 Kudos

Thank you Bernard and SAP!

Former Member
0 Kudos

Hi Shekar,

There is no option to change it without very serious modification to PFCG. You would have to find some sort of method of evaluating each range against a predefined table before the field values in the auth tab (which populate the profile) were filled.

Personally I prefer to keep the concept consistent which, in R/3, is additive.

What I would like to see is the option to populate a copied list without having to expand the rows to fit the selection, but I doubt that will be forthcoming.

Cheers

Alex

0 Kudos

> What I would like to see is the option to populate a copied list without having to expand the rows to fit the selection

Just like the 'copy from clipboard' or 'upload from file' in the report selection subscreen! Oh, yes please!

Former Member
0 Kudos

SE16 and PFCG is like comparing apples and bananas.

SE16's selection screen generates a query for which some values can be excluded.

PFCG org levels update a table with the values which will later on be permitted.

So you would not only need to change PFCG, but you would need to change the AUTHORITY-CHECK itself.

Can't see that happening. Being able to range is a pain enough...

Cheers,

Julius

Edited by: Julius Bussche on Aug 28, 2009 12:36 PM

Fruit corrected...

Former Member
0 Kudos

Guys,

Thanks a lot for your replies. But i suppose we still didnt have a definitive answer - so i would prefer to keep this going.

I am pleased for myself that the question has invoked replies from the top guys on this forum.

Coming back to what i asked (with example): If we have a request to have a user get access to all plants from AAAA to ZZZZ but not to AABN and AACK and BFGH and RKML, then the input wouldbe like this:

From To

AAAA AABM

AABO AACJ

AAAL BFGG

BFGI RKMM

RKMN ZZZZ

Imagine if the restriction is on 10 different plants.............

I dont know if i am asking for the moon, but i dont see any reason on why it shouldnt be possible.

Anyway, the idea of giving SE16 options was more to make people understnad on what was on mind and not to compare apples and bananas

Former Member
0 Kudos

Thanks to everyone for the suggestions and views. I have posted a message with SAP about this and if i get more information before you do improable situation, i guess)

I will keep everyone informed

Former Member
0 Kudos

Yes, There should be an enhancement in the way we enter values. I am trying to Exclude only one value (RSUSR002) from the auth field "OBJNAME" under S_DEVELOP and I am not sure how this can be achieved. Meaning, for a particular role, I want to give all the values to OBJNAME except RSUSR002. Can some one help?