OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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

>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

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!


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC