Problem with ITS bwwf_wi_deci service in WebSEAL sessions

[Former Member]

Hi SDN friends,

We are implementing SSO with the following ...

IBM TAM 5.1

SAP Portal 6.0 SP13,

Internet Transaction Server 6.20 SP19

SAP 4.7 Backend

This is for an ESS application. The problem we are encountering is that when a manager accesses the workflow inbox service (ITS service), and they click on the approval button for a given approval request, we get an 'Access is denied' screen returned.

I have spent much time investigating this and it seems to appear because WebSEAL is failing to catch a particular circumstance whereby javascript in an ITS template is generating a URL.

The problem is definitely on the ITS side (ie. Portal is not the cause of this problem). If I execute the transaction through WebSEAL directly through ITS (ie. avoiding Portal) I encounter the same error.

It seems that the following javascript ...

function return_bwsp()

{

location.href="`<sub>ret_url`&</sub>okcode=WORK&BW02_1400-CHOICE=BAIN&_{dec_state=1&}confirm_url=`~confirm_url`";

}

at runtime is sent out like the following ...

function return_bwsp()

{

location.href="/scripts/wgate/ze000009657d04/~flN ... etc ...etc _{confirm_url=/scripts/wgate/bwwf_wi_deci/} ... etc ...etc";

}

... and this code passes through WebSEAL unchanged. Of course, what should occur is that the WebSEAL junction should have been appended at the beginning of the /scripts/wgate instances.

My WebSEAL consultant tells me it is not possible for WebSEAL to capture this scenario. Has anyone else seen this and managed to overcome the problem?

Any thoughts would be appreciated and rewarded.

Thanks

John Moy

[Former Member]

Our TAM expert says that you should look in the ITS integration guide from IBM, specifically at the section about updating the Junction Mapping Table to have /scripts/wgate as part of the jmt.conf.

[Former Member]

Thanks Glenn,

I will follow up with our WebSEAL contact.

Regards

John

[Former Member]

For All,

I have figured out the problem. It relates to ITS session cookies (cookies named ~session, NOT the MYSAPSSO2 cookie). When using the workflow inbox there are two cookies involved, one relating to the inbox and the other relating to the actual workflow screen which is launched within the inbox to perform the approval. When using a direct (non WebSEAL) connection, these cookies are both stored on the client and all is fine. However, when using WebSEAL, it renames the cookies (and more importantly, removes the realm from the cookies) which causes the second one to overwrite the first. The result is that ITS loses its session. We have found that if we turn off cookies at the ITS end, the scenario works through WebSEAL, however we are now investigating whether WebSEAl can be configured to prevent the second cookie overwriting the first.

Hope this helps any others encountering this in future.

Regards

John Moy