Security Concept

This part of the documentation covers the following questions:

Security Levels

R/3 data are accessed via several security levels within a distributed client/server environment. Each level has its own security mechanisms.

 

MTS

The MTS is completely integrated into the security mechanism of Windows NT.
Related business components are combined in the MTS in packages. Each component provides its services via a fixed set of interfaces.
Each package as a whole allows the definition of roles to limit the access to its components. An MTS role is a symbolic name that takes up an NT user group and assigns it to a package. A role determines access activities to the components of a package. If a user accesses a component in a package, the MTS checks whether this user is assigned to the role that allows access to the corresponding business component.
For the generated DCOM proxies, by default, no MTS roles are predefined. They must be defined explicitly in the MTS to limit access.

R/3 System

Firstly, limits to the RFC access to the R/3 system are set via destination. The standard protection mechanism identifies the RFC accesses to the R/3 system. To log on to the target system, enter an R/3 user ID and a password.
Secondly, any remotely called function modules and BAPIs as well as their objects or even individual fields can be protected via authorization checks. As a rule, authorization checks are executed only if they are programmed in the source coding of a BAPI or function module and not explicitly excluded from the check. During such a check, the system compares the values predefined via a user profile to the values specified in the program before an action is executed. This means that a user can execute an action only if the authorization check was successful for each field contained in the object.

Destinations and Logon Data

To be able to establish a connection to the R/3 system, you need a destination. A destination specifies technical parameters (for example, host name) that uniquely identify the target system, security options, and logon data for the users that are authorized to access the system.
These destination parameters are administered independently from information on the generated DCOM proxies. DCOM proxies know nothing about destinations or logon data.
Any connection parameters that specify a particular destination, such as host name of the server machine, system number, or logon data (userID, password, client number, logon language) and safety options, are stored in the Registry as encrypted entries. Any missing logon data must be filled in by the client program at runtime.

Note:

To minimize the amount of coding within the client program, you can assign a default destination to all objects of the program. If no other destination is specified in the client program, all objects use the default destination to access R/3.

Scenarios and User Mapping

Scenario 1: Explicit Logon

With explicit logon, the R/3 system is accessed via the R/3 user, similar to a logon using the SAPGUI.
Information on logon data (destination, userID, passwort, client, language) for accessing R/3 must be specified at runtime of the client program.
The client application, in this case, provides the corresponding fields in the logon window. In the destination maintenance, user name and password of the logon data are not predefined.

In this scenario, the scaleability is low since the resource pooling is not used. Only those accesses are shared that use the same R/3 user.
This scenario is suited for use in the intranet. The number of users is known and the SAP system can be dimensioned accordingly.

Scenario 2: Implicit Logon

To access the R/3 system, each explicit R/3 user is assigned to a number of NT users. For each explicit R/3 user a separate destination is maintained, which thus defines a "collective user". Besides the connection parameters all logon data are predefined in the destination maintenance of the DCOM Connector; they are loaded dynamically at runtime of the client program. For one physical R/3 system several logical destinations are maintained with which different R/3 users are associated.

In this scenario, a large number of NT users is mapped onto few R/3 users. Since an explicit R/3 user is usually associated with groups of NT users, the user contexts in R/3 are reduced and the advantages of the pooling mechanism for R/3 accesses are used. To make sure that the users access the "correct" destination, in MTS roles can be maintained (see below).

Scenario 3: Single Logon Mode

You can use this mode only if the MTS server has been registered as trusted system in the SAP system, meaning that R/3 trusts MTS to perform the user authorization. In this case, no user ID or password must be specified in the destination maintenance of the DCOM Connector. Instead, set the option Single Login Mode. In the client program, no logon window is required. The system executes an authorization check on the logon data for logging on to the trusting system. The data entered in the destination maintenance are checked against the field values of the corresponding authorization object in the trusting system.
For using this scenario, you must maintain user tables in the R/3 system that map the current NT users onto the given R/3 users.

 

Limiting Access Using MTS Roles

Into the scenarios described above you can integrate the security services of the MTS to limit access authorizations. You can use MTS roles to define classes of NT users with identical access authorizations.
By default, no roles are predefined for the generated DCOM proxies. Access limitation for the respective MTS components at runtime takes effect only if the administrator defines roles.
As administrator, you can limit accesses to the three levels of the MTS hierarchy for:

Access control for components and on interface level is described in the MTS documentation under "Enabling MTS Package Security". The concept that applies is that of "declarative security" as described in the MTS manual.

 

Limiting Access to Destinations

From the technical point of view, the concept of "programatic security" is used, but the actual procedure of executing an authorization check hardly differs from the check on the component and interface levels.
To limit access on the destination level, the adminstrator must, in addition, specify the name of a role in the option MTS role when maintaining the destination parameters in the DCOM Connector. See also Administration and Destination Management.
The name specified must correspond to the name of the MTS role that is assigned to the MTS package in which the respective component was installed. If the same destination is used for several packages, the roles must be defined separately for each package. Even though the names of the roles are the same, each package has its own list of users (see MTS documentation Adding a New MTS Role).
The administrator can then enter this role for components (see MTS documentation under Enabling MTS Package Security).
Only the users defined in this role can access the respective components via this destination.

Handling Logon Data in the Client Program

For handling the destinations in the client program, you must distinguish between these three cases:

Prerequisites

Procedure

To provide connection parameters and logon data in a client program for RFC accesses, proceed as follows:

  1. At design time, lay out the logon window scenario-dependent.
  2. At runtime of the client program, enter the missing logon data.
    If the destination does not contain the user ID and/or the password, the client number, or the logon language, this data must be entered at runtime of the client program.
  3. In the program, assign the selected destination and the respective logon data to the business objects.

Example: VB Coding

Dim oOrder As SAPSalesOrder

    Set oOrder = CreateObject("SAP.SalesOrder.1")

    oOrder.Destination = cbDestination.Text

    oOrder.UserID = txtUserID.Text

    oOrder.Client = txtClient.Text

    oOrder.Password = txtPassword.Text

    oOrder.Languange = txtLanguage.Text

Programming Tips for the Logon Dialog

In most cases, there is only one destination used for each application. This destination is then hard-coded in the client program. However, there may be some cases in which you may want to provide a selection list for destinations in the logon dialog. You can get this list from the configuration data of the client application or from the configuration data of the MTS server.
To be able to use the latter, the package CCADMIN must have been exported from the MTS server and the client PC must have been configured to allow calling remote components. For the procedure, see also Exporting MTS Packages.

Reading Destinations from the Registry

To access entries in the Windows Registry, you can use the component SAP.CCRegistry.1. After installation of the DCOM Connector, this component is part of the package SAP R/3 DCOM Connector. You can use the method GetDestinations to read the destinations maintained in the DCOM Connector and to make them available.

Example: VB Coding

Dim oRegistry As CCRegistry

Dim rsDestinations As Recordset

    Set oRegistry = New CCRegistry

    Set rsDestinations = oRegistry.GetDestinations

       While Not rsDestinations.EOF

         ' Adding entries into the Listbox

          cbDestinations.AddItem (rsDestinations.Fields(0))

          rsDestinations.MoveNext

       Wend

   ' setting the first element from List

    Index = 0

    cbDestinations.Text = cbDestination.List(Index)

Displaying Predefined Logon Data

If the administrator has already entered some logon data (for example, client number and logon language) when maintaining a destination, you can read it from the Registry using a local instance of the object CCRegistry and the method GetOptionsAsRecordsets and display it in the logon window.

Example: VB Coding

Dim rsOptions As Recordset

    Set oRegistry = New CCRegistry

    Set rsOptions = oRegistry.GetOptionsAsRecord(cbDestination)

    If Not rsOptions Is Nothing Then

          rsOptions.MoveFirst

          txtClient.Text = rsOptions.Fields("Client")

          txtLanguage.Text = rsOptions.Fields("Lang")

    End If