Question:
Hi,
I want to hide or remove or block the access og Portal users to the command field in back end system.
Does anybody know if it is possible to block or to remove for one or several roles/users the command field in the SAP toolbar menu in order to avoid these users to type any transaction code in this field...
Is it something that can be managed with a specific user parameter in SU01 or with an authorization object in PFCG?
thks & rgds
Laurent
_________________
LAURENT
Answer:
Why?
How is this related to security?
Answer:
Why?
How is this related to security?
Shhh! It's a secret!
Answer:
This is not controlled through authorisations. I don't think there is any way of doing this - and beside, what would the point be? If the user is not supposed to have access, he should not be authorised.
Answer:
It can be done, but at this point, must be done through the way you develop the iViews. SAP must be getting this question posed, so there may be a property added in the future to the standard Transaction iView - in the meantime, I believe you'll need to have an ITS service created for the transactions and serve that up in the portal, rather than creating a traditional iView, there are other ways through development, but I understand this way to be the most straight-forward.
As far as why this would be considered, it plays into a lot of decisions about portal architecture and how to make the content available externally without (1) adding a lot of additional administration and synchronization issues and (2) not providing unintended access to external users (customers, shippers, suppliers, etc).
What's "common" access for internal users may be different for what's common for external users (and different scenarios of the latter), so you can either create more roles for different circumstances, and deal with the additional burden of keeping the administration in sync, and/or you can try to shut down folks from navigating from what they've been provided at the portal.
It's a decision to make in terms of where you want to apply effort for user administration.
Synchronization of access between portal and R/3 can be a pain; so if you can depend on keeping the door closed to navigation through the command box at the portal, you can keep the back-end security more general, at least in terms of display.
Regards,
Vincent
Answer:
Is your concern that the user could enter tcode /nTARR even although they are not authorized for it or that the tcode may or may not exist, or be invisible even?
If the user knows enough to be able to trick the sessions and backward / forward movements involving the little command window and the ghosts that pass through it, then they will probably know enough about SAP's GUI design that you do not need to see the "command window" to put any value into the field anyway.
If the user abruptly leaves the application, then that is just one of the those unfortunate things about RFC.
You can also limit and contain the ability of the user from abusing this by restrictive access and adopting development techniques as per SAP's recommendations.
Tarr
Answer:
I'm not sure what "little ghosts that pass through it" means, but it does bring up a point about the GUI, in that the portal is ultimately intended to deliver content independent of the SAP GUI.
Using Transaction iViews, and Bex Reporting for that matter, will lock you into desktop support of the GUI for the content to work.
Moving away from these approaches solves the command box concern, as well as support of desktops to deliver content.
I change my answer - "you can't do it!"
Answer:
But you can try, and you can control it to a large extent and you can patch and you can have developer guidelines.
Removing the "command window" is one of the weaker controls.
Tarr
Answer:
There is another interesting possibility if you are interested. In addition to transaction codes, system commands can also be entered such as /o, /n, /$, /h etc via the window or GUI.
It is possible to contain the last one, not only via auths (no auths are required for handling the session and getting to the ok-code), but also via the work process for the debugger engine's session.
You can turn it off via an rdisp value and even a user with SAP_ALL or one who has not logged onto the application yet will get the message "Debugging Impossible at this time."
You can also remove the dynamically switchable nature of the param, but it is probably still not 100% water-tight.
_________________
Try Search
Else SAPNet
Otherwise It was designed not to work.
____________________
Answer:
From what I hear from our portals guru, this is set using a registry key during SAPgui installation. We're using portals extensively, and it seems to be rather difficult to hack into the system using t-codes... have to admit I've only tried for a few minutes, though. I guess that for normal users, this should be sufficient.
Answer:
From what I hear from our portals guru, this is set using a registry key during SAPgui installation.
THis helps.
We're using portals extensively, and it seems to be rather difficult to hack into the system using t-codes...
... ' '
have to admit I've only tried for a few minutes, though.
That should be sufficient for the wp.
I guess that for normal users, this should be sufficient.
Yes, but for the second last % it would depend on whether you monitor your normal and other users. Without doing that (responsibly) you will never know.
There is another associated topic called skills, but that is a very different topic.
Tarr
_________________
Try Search
Else SAPNet
Otherwise It was designed not to work.
____________________