How do I limit what my users can do when they log on to a SAP instance?

SAP user security is done via roles. A role is basically a group of transactions, authorizations, and authorization objects bundled together for use by a group of users with common functional needs. This group definition is saved and generates a profile which is attached to the SAP user who needs it.

People often get intimidated by SAP security – there are thousands of transactions, authorizations, and objects. It helps to think of all this is simplistic terms.

Let’s say you have a user who needs access to one transaction in the SAP instance. All he needs to do it log on, go to transaction SPAD, and print a list of available printers. That is his whole job, to create this printer list once a day. So he needs the authorizations that allow him to log on to SAP, to go to the SPAD transaction, and to print the list to any available printer. He has * to all printers. He basically needs a role containing the transaction he is allowed to do, SPAD, and the authorization object S_SPO_DEV set to all because he can see and print to any printer.

Then let’s says a new check printer gets added to SAP, and we don’t want the user to be able to print his printer list to the new check printer. So we change authorization object S_SPO_DEV to a list containing authorizations for the printers to which he can print, excluding the check printer. His dropdown list for printers won’t even show the new printer now. And he will be able to print to any printer in his printer authorizations list.

This is a simplistic example but you can see how it works. SAP security can be very tight or very loose. In general, it is loose in DEV, using a modification of the SAP_ALL profile – sort of God-like powers and what the Basis people normally use since it already exists and why make a role that does the very same thing? - to allow every DEV user to do everything with the exception of Basis tasks. QAS may be a little tighter, or a combination, allowing the user SAP_ALL during training but limiting the user to his/her PRD role in another client on the last day so he can test the role he will really use out. In PRD, of course, users should only receive the rights to only what they absolutely need to do.