Login and user management on AGate
By Mario Perez, Alexander Hildenbrand, Bernd Matzke, and Peter Zencke
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
"The AGate (Application Gateway) serves as the heart of the ITS," reads SAP R/3 on the Internet, by Mario Perez, Alexander Hildenbrand, Bernd Matzke, and Peter Zencke. One of the most important tasks of the AGate is login and user management. This excerpt from SAP R/3 on the Internet discusses how AGate deals with this task.
The AGate uses the entries for user and password in the service description to execute a login procedure to the R/3 System automatically. If the entries do not exist in the description, the system requests them from the user when it starts the IAC. The login procedure takes place transparently when the entries exist. Internet users therefore have the impression that they operate an R/3 application without having logged on or they fail to notice that they work anonymously in an R/3 System.
Developers will often find it advantageous to define a generic Web user as an R/3 user with quite limited access rights. However, some applications may benefit from individual logins by different users so that their authorization profiles can control the application exactly. Restrictive programming can limit the options available to a Web user to a specific application. Once a user has logged on anonymously, the system can request a specific Web user ID at runtime and check it according to specific applications, such as particular BAPIs. This procedure applies to some of the IACs delivered by SAP, especially for the application process. The system can also generate a Web user at runtime and send a message that contains the ID to the user. Should applicants later query the status of their job applications, they can enter the ID to gain access to the information.
On an Intranet, the system can use the normal R/3 login procedure to check authorizations because R/3 users already exist. If, however, the system should address 'unknown' user groups, as on the Internet, the login must take place for a generic R/3 user. This approach can also apply to many Intranet applications that offer unspecific services, such as an employee catalog. Application-oriented authorization checks with BAPIs can supply additional legitimization with a generic login.
Did you like this tip? Hate it? Send us a note to let us know your thoughts.