There are many ways to authenticate a user against a WebAS system. This guide addresses common

problems observed in this area.

How to achieve anonymous logon to a WebAS system?

It is never possible to have anonymous access to a WebAS system. The solution is to configure a predefined

user under which all HTTP requests can be executed. This can be done by setting up an ICF node (and all it

children!) so that the application runs under a predefined user name. Recommended is to do this very

limited for very specific BSP applications only, and not complete subtrees in ICF.

Double click on the corresponding BSP application node in ICF tree.

On Service Data tab, fill the Anonymous Logon Data block with the login data of the valid

user id, under which all the users will actually access the application. After that, all the users will be

atomatically logged on as this anonymous user id, without any login prompt displayed.

It is cautioned to use this technique only in special cases, and that the user id used must also have very

limited rights (only the minimum required for the application).

Side Effect: be careful when debugging such an application, as it will run under the anonynmous user ID,

which will probably be different from the SAPGUI logon language under which breakpoints have been set.

How to transfer authentication from SAPGUI session to browser session?

For the scenarios involving a browser start from SAPGUI, SSO was only introduced in 620SP58, 640SP15,

700SP05 (see SSO during the testing of BSPs in Transaction SE80).

The following requirements must be met to make it work:

1. profile parameters login/accept_sso2_ticket = 1 (when the certificate is signed by SAP CA)

and login/create_sso2_ticket = 1 | 2 (when the certificate is self-signed).

2. ICF node default_host/sap/public/myssocntl is activated

3. Domain name corresponds to the internet standards allowing to transfer cookies (see also Naming

Requirements for Hostnames and Domains).

If you want to use this functionality for you own applications, use CL_GUI_HTML_CONTROL class. It contains the method ENABLE_SSO (see also SSO for local BSP calls using SAP GUI HTML Control) to allow to set SSO2

cookie for the called url. This is implemented in such a way that the actual first HTTP request goes to ICF node /sab/public/bc/myssocntl, which generates the cookie.

Then you can use class methods SHOW_URL (in all cases) or DETACH_URL_IN_BROWSER (if the

corresponding SAP GUI patch level is available) to make the call.

Why does logon application only show limited number of languages?

On the ICFX login screen, the Language combobox lists only 'EN' and 'DE', despite the fact that other

languages are also installed.

Check which languages are returned by the function module SCP_ALLOWED_LANGUAGES. If it's just 'E' and

'D', see the documentation on this function module to resolve the problem.

Why does authentication in the URL suddenly fails for my stateless BSP application?

To skip the login procedure, one can specify user and password directly in the URL. For example:

http://myhost.copmany.com:8080/sap/bc/bsp/sap/it00/default.htm?sap-user=me&sap-password=mypass

The reason for the failure is in principle a case of dropped authentication, which happens when SSO2 cookies

are not active. Let us look at a reduced trace.

GET http://myhost.copmany.com:8080/sap/bc/bsp/sap/it00/default.htm?sap-user=me&sap-password=mypass

HTTP/1.1 302 Moved temporarily

Location: /sap(bD1lbiZjPTAwMA==)/bc/bsp/sap/it00/default.htm?sap-user=me&sap-password=++++++++

GET http://myhost.copmany.com:8080/sap/bc/bsp/sap/it00/default.htm?sap-user=me&sap-password=+++++++

HTTP/1.1 401 Unauthorized

WWW-Authenticate: Basic realm="..."

On the first request, the user (sap-user) and password (sap-password) are supplied as URL parameters.

This validates that specific one request. However, directly thereafter, even before the BSP runtime is started

the ICM&ICF layers will scrub the incoming request of all authentication information. One of the steps is that passwords that are recognized, are replaced with a ++++++++ sequence. Now, as BSP generates a redirect

URL to complete its mangling process, the next URL will have the sequence sap-password=+++++++.

With the next request, we now have an incoming HTTP request with a valid sap-user, but an invalid sap-

password. As SSO2 was not active, the first HTTP response had not set any SSO2 cookie, and as the application is running stateless, not alternative authentication via the sap-contextid is possible. The

browser will now suddenly display its Basic Authentication popup, based on the rc=401 received back from

the server.

The only solution would be to activate SSO2 cookies on the server. The first request will then set the SSO2

cookie, which will then hold the authentication information for all subsequent HTTP requests.

When does user mapping from SAP portal fail?

Effectively the use of user mapping is equavalent to the problem described above at "HOME:#Why does

authentication in the URL suddenly fails for my stateless BSP application?". Once the portal calls a stateless

BSP application and no SSO2 cookies are active, or the portal server has set a SSO2 cookie that is not

accepted by the server, the use of user mapping will fail.

Note: the SSO2 spec states that only one SSO2 cookie is allowed to be active. This means that once a server

sets a cookie for a specific domain, all other servers in that domain must accept the cookie (all servers must

be in a trusted relationship). Otherwise a receiving server will get a cookie that is not accepted, but will not

be in a position to set its own cookie.