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.
Service Datatab, fill the
Anonymous Logon Datablock 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:
- 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).
- ICF node
- 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:
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.
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 and 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
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 "Logon". 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.