The Authentication Process (SAP Library - Web Applications and Business Server Pages)

The Authentication Process

Uses

If a browser requests a page from a Web server, it usually uses an HTTP GET command to fetch the page, provided that the page can be accessed publicly. Initial access to an open Web page typically looks as follows:

	¾ ¾ ¾ ¾ ¾ ®	GET
	¬ ¾ ¾ ¾ ¾ ¾	return code = 200 (OK) and page contents

In principle an SAP Web AS System behaves like a usual R/3 System, in which each R/3 session must be assigned to a specific user ID. Even if PUBLIC pages are supported, they are not considered normal.

Note

PUBLIC pages run under the SAPSYS service user. It is recommended that you only use these public pages to access style sheets from the MIME repository and for special application cases.

Usually, if a browser access a BSP application, the SAP Web AS will return the HTTP request and ask for authentication information. The browser displays a small dialog box that requests the user name and the password. This information is then returned with the next request as an authentication header (in basic authentication format).

The usual process is then as follows:

	¾ ¾ ¾ ¾ ¾ ®	GET
	¬ ¾ ¾ ¾ ¾ ¾	return code = 401 (authentication required)
	¾ ¾ ¾ ¾ ¾ ®	GET (with authentication: header)
	¬ ¾ ¾ ¾ ¾ ¾	return code = 200 (OK) and page contents

Note the following with basic authentication:

The browser dialog box can only request the name and password. You cannot enter any information about the SAP clients or the language. (This information can also be transferred using URL parameters.)
The information is entered via the browser and, as soon as it is received from the user, it is sent to the server with every request.
The user name and password are only coded with a Base64 routine and are therefore not secure.
You have no option of changing the information or deleting it from the server. As soon as the browser receives this information, it sends it with each request. As a result the request is accepted from the SAP Web AS for further processing (provided that the logon information is correct). This means that it is not possible to log off if you are using basic authentication.

The SAP Web AS supports SSO2 cookies for the authentication (see also Using Logon Tickets). This has many advantages:

As soon as the first authentication is made using the SAP Web AS (it is recommended that you execute this using HTTPS), a digitally signed is output and the user name and password are not transferred using Base64 coding.
SSO2 cookies can be used to log on once, if many servers of this type were configured, so that they can all accept the same logon ticket.
SSO2 cookies help with implementing a logoff option, where the Sso2 cookies are simply deleted.

Note

Note that an SSO2 cookie is approximately 1 KB and this information is transmitted to the server with every request from the browser.

The logon application SYSTEM requires SSO2 cookies and only supports logon using SSO2 cookies. The SYSTEM itself must be declared as a publicly accessible application, so that the user is presented with an initial screen in which all information that is relevant for the logon can be entered.
At the next request, the system tries to log on the user with his or her own data. It then sets an SSO2 cookie and starts the requested BSP application.

The usual logon process is then as follows:

¾ ¾ ¾ ¾ ¾ ®	GET /bsp/XYZ
¬ ¾ ¾ ¾ ¾ ¾	return code = 302 (Redirect) to /bsp/system/logon.htm
¾ ¾ ¾ ¾ ¾ ®	GET /bsp/system/logon.htm
¬ ¾ ¾ ¾ ¾ ¾	return code = 200 (OK) and logon screen
¾ ¾ ¾ ¾ ¾ ®	POST /bsp/system/logon.htm
¬ ¾ ¾ ¾ ¾ ¾	return code = 302 (Redirect) to /bsp/XYZ with SSO2 cookie

If a logoff sequence is required, only the SSO2 cookie must be deleted and, in the case of stateful applications, the application must be changed back to stateless mode, in order to clean up the roll area. In this context logoff means that the authentication information must be deleted, so that at the next request the user is asked to enter this information.

In order to provide help for logon screens, you can use the logoff.htm page in SYSTEM. The BSP application must define one logon button and place the URL of the logoff page as HREF. The demo BSP application SYSTEM_PRIVATE contains an example of this.

Logoff Example

The logon application SYSTEM also contains a logoff.htm page, which can be used to delete the SSO2 cookie and also to return the application to stateless mode, so that the roll area is clean.

This is usually integrated in a BSP application as a logoff button, which contains a reference to the logoff page, such as:

<a href="<%=CL_BSP_LOGIN_APPLICATION=>
SET_LOGOFF_URL_PARAM( page = page )%>" >Logoff</a>