12-06-2007 9:22 PM
Hi security experts,
I have a question regarding authorization objects and transactions.
When SAP checks for user access to transactions, are the authorization objects verified against the action the are related to or as independent authorization object not linked to transaction?
How is the logic flow followed by SAP in order to grant user access to certain transaction? Could you please recommend me any document or link where I could find such info?
Many many thanks in advance. Regards,
Imanol
12-06-2007 9:45 PM
Hi Imanol,
A basic overview of the auth process for you.
1. User logs in, is authenticated via user ID & password
2. The data from the profiles in their user master is loaded into their auth buffer.
3. User executes a transaction e.g. FB01
4. A kernel level check is performed against the user buffer for auth object S_TCODE, value = FB01
5. Any auth object checks assigned at transaction start vie SE93 are also evaluated at this point.
5. If successful SAP starts to go through the ABAP code of the program assigned to the transaction.
6. When the program hits an AUTHORITY-CHECK statement in the code, it evaluates the user buffer for values which meet the check. The AUTHORITY-CHECK references an auth object and one or more values in that object. For FB01 one of the checks would be F_BKPF_BUK: Activity=01, Company code=<whatever> to check that you have authorisation to create in company code <whatever>
7. If you have the relevant auths then it proceeds through the code, doing whatever it needs to do.
8. If you don't have the relevant auths then it will tell you that you don't have authorisation or kick you out etc.
As you can see from the process above, the transaction merely is the frontend to a program and it is the code in the program & the path that you take through the program that determines the AUTHORITY-CHECKS that need to be satisfied.
In SU24 we maintain the auth objects that are needed to run a particular transaction, however there is no dynamic link between the two. This is because the auth checks will differ based on config, how you use the transaction etc.
Hope that helps. If you haven't done already, it's worth tracking down Authorisations Made Easy and the SAP Security Guide vol 1-3. I don't have links to these unfortunately. Another very good resource for this is course ADM940 which covers this in great detail.
Cheers
Alex
12-06-2007 9:45 PM
Hi Imanol,
A basic overview of the auth process for you.
1. User logs in, is authenticated via user ID & password
2. The data from the profiles in their user master is loaded into their auth buffer.
3. User executes a transaction e.g. FB01
4. A kernel level check is performed against the user buffer for auth object S_TCODE, value = FB01
5. Any auth object checks assigned at transaction start vie SE93 are also evaluated at this point.
5. If successful SAP starts to go through the ABAP code of the program assigned to the transaction.
6. When the program hits an AUTHORITY-CHECK statement in the code, it evaluates the user buffer for values which meet the check. The AUTHORITY-CHECK references an auth object and one or more values in that object. For FB01 one of the checks would be F_BKPF_BUK: Activity=01, Company code=<whatever> to check that you have authorisation to create in company code <whatever>
7. If you have the relevant auths then it proceeds through the code, doing whatever it needs to do.
8. If you don't have the relevant auths then it will tell you that you don't have authorisation or kick you out etc.
As you can see from the process above, the transaction merely is the frontend to a program and it is the code in the program & the path that you take through the program that determines the AUTHORITY-CHECKS that need to be satisfied.
In SU24 we maintain the auth objects that are needed to run a particular transaction, however there is no dynamic link between the two. This is because the auth checks will differ based on config, how you use the transaction etc.
Hope that helps. If you haven't done already, it's worth tracking down Authorisations Made Easy and the SAP Security Guide vol 1-3. I don't have links to these unfortunately. Another very good resource for this is course ADM940 which covers this in great detail.
Cheers
Alex
12-07-2007 8:52 PM
>> 8. If you don't have the relevant auths then it will tell you that you
>> don't have authorisation or kick you out etc.
Strictly speaking, depending on the reason for the check being unsuccessfull, a return-code will be set. Depending on how the program reacts to that return code, the user will experience that which the program is designed to do. That might be an <b>e</b>rror, it might be a <b>w</b>arning, or in extreme cases... they get kicked out
12-07-2007 10:20 PM
12-07-2007 11:07 PM
Hi Alex,
Actually, I am quite surprised that Imanol considered this question answerable...
Oh well... for those who want to go a step further looking under the "bonnet", take a look at .
Unfortunately, I never got to the bottom of it (though SAP made several improvements since, if your system is patched) and it was difficult to find support for it (externally)...
<ppt_programmer>If you dig your own hole, then you don't...</ppt_programmer>
Kind regards,
Julius
12-06-2007 9:52 PM
Hi Imanol,
Here I have put some information about Authorizations per definition (would like to send you the link but I have it locally on my laptop). anyways, here it goes and hope it helps you.
-
' A person can log on to a client of an SAP system if they know the
user/password combination for a user master record.
In the SAP system, there is an authorization check every time a transaction
is called. If a user attempts to start a transaction for which he or she is not
authorized, the system rejects the user with an appropriate error message.
If the user starts a transaction for which he or she has authorization, the system
displays the initial screen of this transaction. Depending on the transaction
called, the user enters data and performs actions on this screen. Additional
authorization checks are made for data and actions that are to be protected.
Users are assigned authorizations using roles. The authorizations are
combined in roles and the roles are entered in the user master record.'
About Authorizations Objects:
'Actions and the access to data are protected by authorization objects in the
SAP system. The authorization objects are delivered by SAP and are in SAP
systems. To provide a better overview, authorization objects are divided into
various object classes.
Authorization objects allow complex checks that involve multiple conditions
that allow a user to perform an action. The conditions are specified in
authorization fields for the authorization objects and are AND linked for the
check. Authorization objects and their fields have descriptive and technical
names. In the example in the figure, the authorization object “User master
maintenance: User Groups” (technical name: S_USER_GRP) contains the two
fields “Activity” (technical name: ACTVT) and “User Group in User Master
Record” (technical name: CLASS). The authorization object S_USER_GRP
protects the user master record. An authorization object can include up to ten
authorization fields.
An authorization is always associated with exactly one authorization
object and contains the value for the fields for the authorization object. An
authorization is a permission to perform a certain action in the SAP system.
The action is defined on the basis of the values for the individual fields
of an authorization object. For example: Authorization B in the figure for
authorization object S_USER_GRP allows the display of all user master
records that are not assigned to the user group SUPER.
There can be multiple authorizations for one authorization object. Some
authorizations are delivered by SAP, but the majority are created specifically
for the customer’s requirements.
When a user logs on to a client of an SAP system, his or her authorizations are
loaded in the user context. The user context is in the user buffer (in the main
memory) of the application server.
When the user calls a transaction, the system checks whether the user has an
authorization in the user context that allows him or her to call the selected
transaction. Authorization checks use the authorizations in the user context.
If the user is assigned new authorizations, he or she must log on to the SAP
system again to use these.
If the authorization check for calling a transaction was successful, the system
displays the initial screen of the transaction. Depending on the transaction,
the user can create data or select actions. When the user completes his or
her dialog step, the data is sent to the dispatcher, which passes it to a dialog
work process for processing. Authority checks (AUTHORITY-CHECK) that
are checked during runtime in the work process are built into the coding
by the ABAP developers for data and actions that are to be protected. If
the user context contains all required authorizations for the checks, the
data and actions are processed and the user receives the next screen. If one
authorization is missing, the data and actions are not processed and the user
receives a message that his or her authorizations are insufficient.
All authorizations are permissions. There are no authorizations for
prohibiting. Everything that is not explicitly allowed is forbidden.'
12-07-2007 9:08 PM
>> All authorizations are permissions. There are no authorizations for
>> prohibiting. Everything that is not explicitly allowed is forbidden.'
That is strictly speaking not correct either.
There are many optional authorizations which can be used to grant permissions <b>only if</b> the authority has prior been protected.
There are also authorizations which can be used to "override" if excluded, or "underride" if included in permissions.
Requirements for authority can also be surpressed based on specific contexts (for example, the calling transaction specific context "No check" in SU24, or, IF SY-UNAME checks which can sometimes be found in "private" programs).
Bar only some system specific authorities and config dependencies, when a program is initialised and executed, it is very powerfull and will do most things unless it is stopped or guided in it's path by (for example) authority-checks.
Kind regards,
Julius
12-07-2007 11:09 PM
>> All authorizations are permissions. There are no authorizations for
>> prohibiting. Everything that is not explicitly allowed is forbidden.'
-
That is strictly speaking not correct either.
Hi Julius, then I guess you have to email SAP to correct them.
I took that information from the Netweaver certification manual TADM10
Good luck.
12-07-2007 11:18 PM
Hi Jessicab,
That statement might again have been "application specific". Some applications will check the authority of the calling user (if told to do so).
So, okay, your statement is not incorrect, it is "specific" to TADM10 (transport administration?).
Kind regards,
Julius
12-07-2007 11:35 PM
TADM10 and TADM12 are the official training manuals for the NetWeaver Technology certification program, so I dont think it is application-specific. In any case, maybe it's technology-specific since the statement is valid for all the Netweaver Technology
TADM stands for Technology Administration, but you were close
Have a good weekend.
12-07-2007 11:51 PM
I will enjoy the weekend, thanks.
Kind regards and enjoy the weekend too.
Julius
PS: FYI - the (parts of) text you have copied in that exact form <i>might</i> even have a copyright protection on it.
Message was edited by:
Julius Bussche
12-09-2007 7:45 PM
Hello jessicab,
A slightly off-topic question - I have been gathering information on which courses to do next year, but had not thought of TADM10/12. Can you recommend them?
Kind regards,
Julius
12-10-2007 5:25 PM
Hey Julius,
Sure, if you want to get the Netweaver Certification you can take them. Those courses are part of the SAP Academy. Additionally, for the certification you'll probably need 1 specific-database course (DB2, Oracle, SQL, etc).
You have more information here:
http://www50.sap.com/useducation/curriculum/curriculum-rid=292.asp
Hope this helps you
Jessica.
12-10-2007 5:44 PM