Additional Blogs by SAP
cancel
Showing results for 
Search instead for 
Did you mean: 
thomas_jung
Developer Advocate
Developer Advocate
0 Kudos
Introduction
In the last weblog I took a look at how we implemented Single Sign On for the BSP environment. Now that we have users logged into our BSP system, that is really only half of the solution. Remember that we have a split environment where our BSP system sits on a 620 WebAS on one server and our R/3 system sits on a separate system on release 46C. We also have a BW environment on another server again. We will be connecting to our R/3 system via RFC. The question is how best to setup this RFC?

The Requirements
Our first requirement for this setup was to keep the authorizations as simple as possible in the WebAS environment. Our security group didn't really want to maintain two sets of complex authorization objects. Our goal was to reuse all the roles we already had in R/3 and have all users have one very simple and generic role in the WebAS. We also wanted to pass through to the R/3 environment the users' personalization settings such as date format, time zone, etc.

In the past our company had setup two different types of RFC connections, anonymous ones with a system user ID and password imbedded in it and ones without a user id and password so that you would be prompted for one when making the RFC call. The second option obviously doesn't work from BSP since there is no prompt for authentication. Even if the system could prompt, that would defeat all the work we had done to get SSO into the WebAS. The anonymous option as technically possible but opened up many problems. First you would need lots of authentication on the WebAS before you even make the call to R/3. Even with lots of complex security in the WebAS this option made our security people a little nervous. This also made it very difficult to properly use the user's personization settings on the R/3 side. The solution came to us as a 3rd type of RFC connection that we had never used before - Trusted RFC.

Trusted RFC to the Rescue
Trusted RFC is nothing new to the SAP environment. Nor is it anything specific to BSP. It was simply a technology that we had never had a driving need for before now. Basically setting up a trusted RFC allows one SAP system that trusts another to accept its user authentication without question.

Let's look at our system landscape. We setup in advance that our R/3 system trusts our WebAS. Therefore when it receives an RFC call from the WebAS, it also trusts that the WebAS as already properly authenticated that user. This allows the user's identity to pass through the RFC connection without any exchange of passwords. However this only gets the user into the R/3 system. Once in the system, all the user's regular roles and authorizations are in effect. That way all that time and money you put into building good roles in R/3 is put to further use without any additional authorizations work in the WebAS.

Setup of Trusted RFC
The first thing we need to do is go to our R/3 system and tell it who we trust. You can do this from RFC Destination Maintenance (SM59). Choose Menu RFC->Trusted Systems. From here you hit create to start the process of defining a new trusting relationship. You will be prompted for an already existing RFC connection to this system. This will be used to make the settings in both systems for the Trust. You then will receive the following screen showing you the settings that will be used for the trust:


Destination Setup
Now that we have our systems trusting each other (isn't a little trust a wonderful thing?), lets setup the RFC destination itself. For that we go back over to our WebAS system and go to RFC Destination Maintenance (SM59). Everything is the same as a normal destination until we reach the Logon/Security section. The following are the settings that we use. This allows for a trusted connection for the current user in the user's current logon language.


Authorization Check
There is only one last thing to do before we run off and start making trusted RFC calls. There is a special authorization object that is checked on the destination side before accepting Trusted RFC calls. By default this authorization is not included in any roles - not even SAP_ALL. The Authorization is S_RFCACL. You can read all about this authorization check and the whole process described here in OSS note 128447.

What Happens When Something Goes Wrong?
By now you should be up and running making trusted RFC calls. But you might be wondering what happens when you have a problem. Let's say that the user in the WebAS isn't setup in the R/3 system or that user isn't authorized for the action in question. Well if you don't do any additional coding in your RFC call you will get the following Short Dump in your WebAS:


Here is the example code that produced this dump:


Actually if you debug this code you will find that the first two RFC calls execute successfully. The dump only occurs on the third call. It appears that functions in the SRFC function group can be called even if you don't have an account in the destination system. The lesson there is don't rely on an RFC_PING to tell you that your user's are authorized in the destination system. I created a simple RFC call in our systems that serves the function of the RFC ping (to make sure your destination is correct) but because it isn't in the SRFC group you also get an early authorization check. I put this call at the beginning of my BSP Application (Usually in the ON_START method of my application class). That way if my user or the RFC destination isn't setup correctly we find out right away.

Catching Destination Errors
But you might be thinking that a short dump isn't a very friendly way of letting your users know that something is wrong. The good news is that you can catch these types of setup errors by adding some special exceptions to your RFC call. They are COMMUNICATION_FAILURE and SYSTEM_FAILURE. These two exceptions are always available when making any type of RFC call. They are especially use in that they can put the details of the error into a message area. They are very useful for catching all kinds of error situations and make for a much nicer response to the user. The following is the same program example with these exceptions and the output I received:



Closing
I hope everyone has enjoyed our dip into the deep end of the security pool. Next time we will have some fun with the IGS charting tool. There have been several posts and a few weblogs already on the subject. I will take you through one of our BSP applications as an example and share with you some of the tips we have found.