[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Update: Contributed doc. browser bindings incl. Shibboleth
Thanx Prateek for commenting this! I did though submitted a request for joining the bindings group some time ago. I will try to answer your questions: >(1) How does the user travel from the source site to the destination >site? >In Scenario 1-1 of the Use-Case document, the user utilizes >her browser to select a link pointing to the destination site at the source >site. Selection of this link has the effect of re-directing >the user to the destination site. All of these steps are completely >within the framework of stock commercial browsers and HTTP 1.1/1.0. >What are the corresponding steps in your proposal? In the description they are the same as in 1-1 use-case. > To what extent are they standard? It is an advanced use of existing standards including HTTP/S Base64, JavaScript, XML, PKI and HTML forms. >In particular, i am unable to follow the >steps (p.3): >"The source-site generates an entire SAML assertions > and puts it in a HTML form and returns to the user's > browser which performs the actual re-direct with the > help of some javascript" >What is really happening here? A page is loaded into the >user's browser and it automatically posts into some remote >site. Yes, when the entire page has been loaded, the onload event fires and POSTs the form to the the designated target URL > This has nothing to do with re-direction but has to >do with the effect of some specific Javascript code running >in the "background". Will all browsers implement this code correctly? What we call it is one thing. It does a de-facto redirected POST from a system's point of view. Regarding browsers I can only say that we have verified this with IE 4.0 - IE 6.0 preview, NN 4.0-6.0 and Opera (current version). WAP - I don't think it works as the current limit on documents will make it die anyhow. A browser with JavaScript disabled must have "manual" button- click fallback code. This is a part of the VISA stuff. >(2) Commercial usage of the internet is based upon fairly heavy use >of re-direction. A major challenge with the use of POST is that >interacts poorly with re-direction (RFC 2068, Section 10.3, attached). >Certainly, we can ignore >this type of practical usage but many sites are built around >the idea that once users arrive at the site and authenticate >(implicitly thru SSO) they may be re-directed to an appropriate >URL. In your solution, the user can only be served a HTML page >with a choice of URLs and must re-select a target URL at the >destination site. Oops! I skimmed through the RFC and it points to a serious flaw in our design. But it works like a charm on both IIS/ASP and Appache/TomCat so I believe the RFC is surpassed by server-implementations that probably do entirely different stuff here. Maybe because a server-initiated redirected POST would be fairly useless! I.e. the POSTed login ticket in our running implementation is actually at server-level set to redirect to a target URL, and it seems to be redirected with a GET which is what [most] people really want (and we even took for granted). Oh Lord, have mercy with the ignorant people who gets their stuff to work although they should'nt! :-) Anyone out there who knows what is going on here? HTTP 303 maybe? I will dig up the facts as fast as I can! Anders
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC