
Already the frequently asked question SEC.02 Logon with Different User when Digital Certificates are A addressed the effects of digital certificates when using HTTPS-based URLs. However, there are a number of other factors that could influence the authentication process. Highly recommended is to read the complete chapter 7 on Security.
Especially in test sequences, where it is important to run a specific test with a very specific user, care must be taken with a clear test strategy to ensure that the tests are run in a repeatable manner with the correct test user. There are a number of unsuspecting factors that could play a role during the authentication process.
First and foremost, when HTTPS-based URLs are used, always be well aware of the effect of digital certificates. If there is any digital certificate available within the browser and this certificate is mapped on the server, it could at any time be used as part of the authentication process.
When starting an URL from the ABAP stack, for example as is done by transaction NWBC, the browser will be supplied with a onetime re-entrant authentication token which results in a MYSAPSSO2 cookie being set for the specific user.
When running in a new browser window within an existing browser session, all accumulated cookies are considered for the HTTP requests. Especially in a tabbed browsing environment, one tends to open a new tab to quickly test something different. However, this new tab is just another browser instance within the same process (at least for Microsoft Internet Explorer) and thus shares all the cookies from the other tabs. Similarly, if the URL in the browser is changed to a different location, the cookies within this browser session are still valid and evaluated. These cookies play a critical role during the authentication process and can cause havoc when expecting to be authenticated with a specific user.
A number of recommendations are made here, specifically when user authentication problems are seen within a browser as a way to achieve a structured test environment where tests can run with guaranteed correct users.
First and foremost, disable any tools that will inject a digital certificate into the secure store.
(SAP Internal: the PSE Management application, visible as a little green box in the task bar tray, manages digital certificates and must be disabled for all testing. Once disabled, the tool will remove your personal certificate from the system.)
Also ensure that there are no additional digital certificates available for the browser to use. For Microsoft Internet Explorer, this can be verified under ton tab Content, button Certificates.
To ensure that there are no authentication information passed from SAP GUI, do not start any browser-based testing from SAP GUI, as then the SAP GUI user will automatically be used. Specifically, do not use transaction NWBC when it is needed to test with a different user. (If needed, use it only once to obtain the start-up URL for a bookmark.) Always manually starts the test sequence by entering the test URL in the browser (or use a bookmark).
Consider to disable browser plug-ins if it is suspected that they could negatively influence the test results.
Always close all browsers, definitely all browsers, before starting a test sequence. Never test within a running browser, never test on a second tab within a browser and never use New Window (Control-N) to get a new browser instance for testing. All of these cases will result in a shared cookie store, tainting the authentication information. In all test sequences, always close all browsers first and then start one browser new for the test case. Do this for each test case.
Consider to extend the URL with URL parameters to force the authentication for a specific user. Parameters available are sap-user, sap-password, sap-client and sap-language. These can be added to the startup URL that is then bookmarked for the specific test sequence. (Consider security guidelines when storing passwords locally.)