How do you stop BSPs on WebSEAL for asking for user-credentials?

[Former Member]

Hi

We are currently having an issue with BSP Pages. When we test the BSP pages on the R/3 system they work OK. When we test them directly on the Portal then they too also work. The problem is that they are not working properly on our Intranet.

The intranet that we use is an IBM Tivoli product (also known as WebSEAL). We currently have WebSEAL SSO to our SAP Portal. This is working OK. When we use WebSEAL to access the portal we are prompted to enter our user-id and password so that the BSP page can be displayed. This should not be happening and it defeats the purpose of SSO. I have attached a screen shot document to demonstate this.

Some time ago we had a similar issue where the transactions on the portal (when executed from WebSEAL) were giving us a Webdynpro time-out error. I later determined that the cookie information was not being passed to WebSEAL. To fix this, I went to the Visual Administrator and went to server >> services >> web container and for the web container "sap.com/irj" I went to the cookie configuration to add a session cookie. By doing this I fixed my previous problem.

Coming back to my problem, I had a junction created in WebSEAL to point to the bsp directory (sap/bc/sap/bsp/*) on the host concerned. I had both a SSL and TCP junction created both resulted in error messages - stating that the client (SAP) is asking for user credentials.

Hoping that I have provided enough information above my question is as follows:

(1) How can I get the BSP messages to work on WebSEAL such that it will not ask for user credentials to be entered? Would this involve making a further change to a Web Container? If so - which container also needs a session cookie to be generated?

Thanks

Kind Regards

Rajdeep Kumar

[Former Member · Accepted solution]

Hi Rajdeep,

I recommend that you open a PMR with IBM.

It sounds to me that one or more of the following conditions is true:

1. SAP Login Ticket authentication is not configured among the SAP servers;

2. The SAP Login Ticket is not being passed from the issuing SAP system to the accepting SAP system, i.e. the R/3; or,

3. The accepting SAP system, the R/3, is not configured for Login Ticket authentication.

IBM support should be able to assist with condition 2. The other conditions are covered in SAP documentation.

Regards,

Peter Tuton.

[Former Member]

Hi Peter

I am having an issue with the re-direct and am hoping you might be able to provide a little assistance. If not then not to worry.

My security department have logged a call with IBM 2 days ago yet have not received any response.

In your document you mention that you need to have a junction to AS-JAVA and a junction to AS-ABAP.

We have created the junctions "/sapep" (for AS-JAVA) and "saphr1" (for AS-ABAP).

The junction /sapep" also contains the junction mapping entries "/irj/" and "/SSOTicket/".

The direct URL to the hidden image is : https://uadsfi01.auiag.corp:53001/SSOTicket/1x1.gif. I have tested this (using my user id and password) and it works OK.

When testing the image through TAM (https://test.insideiaghome.iaglimited.net/sapep/SSOTicket/1x1.gif) we get an "unexpected authentication challenge"

I have reviewed the log below and it seems that we are having an authentication issue with the image:

==(START OF LOG)==

2008-06-16-19:59:58.365+10:00I----- thread(136) trace.pdweb.debug:2 /sand/cholt/laura_amweb510_11LA/src/pdweb/wand/wand/log.c:309: -

---

PD ===> BackEnd -

---

Thread_ID:52943

GET /SSOTicket/1x1.gif HTTP/1.1

via: HTTP/1.1 uattam01:443

host: uadsfi01.auiag.corp:53001

user-agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; MS-RTC LM 8; .NET CLR 2.0.50727)

iv_server_name: uatin1-webseald-uattam01

accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, /

iagsapid: 52975

accept-language: en-au

referer: https://test.insideiaghome.iaglimited.net/sapabap.html

connection: close

iv-user: s52975

-

---

2008-06-16-19:59:58.373+10:00I----- thread(136) trace.pdweb.debug:2 /sand/cholt/laura_amweb510_11LA/src/pdweb/wand/wand/log.c:309: -

---

PD <=== BackEnd -

---

Thread_ID:52943

HTTP/1.1 401 Unauthorized

content-type: text/html

date: Mon, 16 Jun 2008 09:59:58 GMT

cache-control: no-cache

content-length: 1787

www-authenticate: Basic realm="Upload Protected Area"

server: SAP J2EE Engine/7.00

expires: 0

pragma: no-cache

connection: close

==(END OF LOG)==

When logging into the SAP Portal directly general user ids have no problem accessing this (Non-Administrator portal users), however through Tivoli it is causing an issue.

Do you know what may be causing this issue?

Thanks in advance for any assistance you can offer.

Kind Regards

Rajdeep Kumar

[Former Member]

Hi Peter

I think I now know what's happening.

WebSEAL is successfully SSOing to AS-JAVA, however not with AS-ABAP. Therefore there will be work required on WebSEAL to SSO to both AS-JAVA and AS-ABAP.

The document that you wrote back in 2005/2006 assumes that WebSEAL first attempts to SSO to AS-ABAP.

We are using WebSEAL 5.1 and SAP EP 7.0 (Netweaver 2004S). I am not sure if the behaviour is not different to previous versions.

Having said this - should I follow your document (ie: SSO with JAVA first then SSO with AS-ABAP)? I was thinking that because the SSO to AS-ABAP is not done then this should be done prior to SSO to AS-JAVA. The only problem is that your document assumes that AS-JAVA is the issue.

Any further light you can provide will be greatly appreciated.

Thanks

Kind Regards

Rajdeep Kumar

[Former Member]

Hi Rajdeep,

Yes, you should follow the article, "[Single Sign-On for SAP Netweaver Application Server ABAP with Tivoli Access Manager|http://www.ibm.com/developerworks/tivoli/library/t-ssosapnwas/]".

Note that you have two options for SSO to AS-ABAP from WebSEAL. The first is to use the method outlined in the above article. The second is two configure WebSEAL to send Basic Authentication (BA) credentials to AS-ABAP, supplied by the TAM Global Sign-On (GSO) Lockbox. The second method also required you to configure the AS-ABAP to accept a BA credential, and, more significantly, requires careful design in order to ensure the credentials are kept in sync - Tivoli Identity Manager can assist with this requirement. Therefore, I recommend using the first method, but only if it makes sense in your environment.

As previously mentioned, you really need to examine the flow between the browser, WebSEAL and the SAP systems. You should see the MYSAPSSO2 cookie generated by the AS-JAVA, then have it returned to the browser (via WebSEAL), then have it sent to the AS-ABAP (again, via WebSEAL). If this flow is happening and you are still not seeing SSO success, then there is a misconfiguration in your SAP environment

If not done so already, open a PMR with IBM. The support personnel will - at the very least - be able to ensure WebSEAL is configured correctly.

Regards,

Peter Tuton.

[Former Member]

Hi Peter

Thanks for your response.

The SAP logon ticket has been configured and is working OK. The content from the SAP R/3 system is being displayed correctly on the portal and we are also able to process transactions in the portal.

I have logged a call with IBM and am waiting a response.

This issue seems to only occur with the BSP pages and custom reports executed using an ITS connection. I have read one of your documents "Single Sign-On for SAP Netweaver Application Server ABAP with Tivoli Access Manager." I created the additional junctions as specified, however the re-direct to SSO to AS-JAVA was ignored as BSP pages and ABAP reports are executed on the ABAP stack. I tested this and the problem was not resolved.

Do you have any other ideas as to what could be causing this problem. Any further information will be greatly appreciated.

Thanks

Kind Regards

Rajdeep Kumar

[Former Member]

Hi Rajdeep,

Interesting... I'd need to review network and WebSEAL trace files, which is what will be requested by IBM support. I'm confident that the problem will addressed by IBM support. Let's wait and see what happens.

Regards,

Peter.