Skip to Content

BSP SSO Web Dispatcher

We have a BSP application running in EP using Single sign On. When we use the web dispatcher the SSO is not working and users are prompted for log on. Has anybody faced this issue?

Let me explain the details:

EP6 SP2 and

WAS6.4

We have this BSP application running from system a.company.com:1080 (where a is the centeral instance of the WAS system) and our web-dispatcher is running on a.company.com:1085.

When we used a.company.com:1080(WAS setting in system definition) the SSO works fine but when we use a.company.com:1085 (web dispatcher path) the SSO dosent work and users are requested for authentication.

thanks in advance.

Regards

Raja

Note i have also posted this question in EP implementation forum.

/thread/28142 [original link is broken]

Message was edited by: Durairaj Athavan Raja

Add a comment
10|10000 characters needed characters exceeded

Related questions

2 Answers

  • Best Answer
    author's profile photo Former Member
    Former Member
    Posted on Feb 16, 2005 at 02:29 PM

    I do not see the SSO cookies in both cases.

    As far as I know the SSO2 cookie used by BSP is <b>MYSAPSSO2</b>. There is no such cookie in your examples.

    However the authentication can be done in your case just from URL or from the basic authentication. Also the session ID is probably provided (in this case there is no need in authentication).

    It would be more usefull to check the <i>whole HTTP trace data</i> for these two different requests.

    Add a comment
    10|10000 characters needed characters exceeded

  • Posted on Feb 16, 2005 at 09:42 PM

    Raja,

    Artem is correct that the MYSAPSSO2 cookie is not in the trace.

    There is one constrain about SSO2 cookies that you must understand. They are set for the complete domain, and on the root path. The specification says that there can be exactly one of these cookies in the browser.

    Thus, when the browser connections to the first machine in the domain, it sets a SSO2 cookie. Now the browser connections to any other N machines, and they either accept the cookie or not (more below). Let us assume they do not accept the cookie, then they prompt for a user name and password, and authenticate you again. Now this machine wishes also to set a SSO2 cookie. But you have already one (which it did not accept). So NO new cookie can be set. This is the information that is actually reflected in the SSOLIST cookie. It is those cookies not accepted. Check documentation and notes on this keyword.

    What is SSO2 cookie? It is just your name that is digitally signed by a certificate. On the receiving machine, it will look at this cookie, and only accept it, if there is a trusted relationship between the machine that issues the cookie, and the one that reads the cookie. This trusted relationship you must configure and setup. In SDN, there are many documents on this. Specifically see the thread on which we list all weblogs for a good link!

    The other problem/aspect is that your name in the SSO2 cookie must be matched onto your user name in the incoming system. This is stored in some table, somewhere. (I just ask our IT people here for help, don't know the gory details.)

    bye, brian

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.