[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Update: Contributed doc. browser bindings incl. Shibboleth
Anders, I spend some time researching the situation with POSTs and re-directs and came away with the sense that things do seem to work out OK. A POST cannot be re-directed BUT it is acceptable that the result of a POST be a redirect containing a GET. This is supported both by RFC 2068 (cf. Section 10.3.4) and by other first hand sources (e.g., http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html) Here are the essential steps: 1) User accesses a link at the source site (GET ...(has TARGET within it somewhere)) (2) source site serves up an HTML page containing a form (3) (POST) User clicks on a form SUBMIT button and arrives at the destination site with TARGET on the URL and the assertion (4) The destination site verifies that the included assertion is acceptable and redirects the user to TARGET I would strongly recommend we leave JavaScript out of the profile. Obviously, it is available as an optimization for those who are willing to live a little dangerously. By bringing it in formally we are opening the door to much controversy. QUESTIONS: (1) Do we need to mandate assertion confidentiality? Notice that the assertion itself is loaded into the user's browser and can therefore be "read" by the user. Should some form of encryption be mandatory here? (2) Assertion Integrity and Source Site Authentication: Given that the assertion is travelling thru a third-party (user's browser) it seems to me that it would be mandatory that the assertion be digitally signed. (3) But what about replay attacks? Even with (1) and (2) (signed assertion which has been encrypted) the assertion and form can be copied and used from a completely different browser by a completey different user. How can we guard against this? Notice, this is obviated by the use of a "one-use artifact" as found in the current web browser profile. Look forward to hearing more about these issues. - prateek >>-----Original Message----- >>From: Anders Rundgren [mailto:anders.rundgren@telia.com] >>Sent: Friday, August 03, 2001 1:40 AM >>To: Mishra, Prateek; security-services@lists.oasis-open.org >>Subject: Re: Update: Contributed doc. browser bindings incl. >>Shibboleth >> >> >>Prateek, >>I believe that your interpretation of my slides is not >>entirely correct. >> >>The connection between the link on the source site and >>the target resource may be of two types: >>- The target may be a virtual resource. "Main Catalog", >>"Manufacturing". >>- The target is an URL >>In both cases the description of the target is a part of the >>request. I.e. >>step #5 does not apply. >> >>The destination is [typically] an RP security-server taking care of >>auth* requests and redirecting users to the appropriate >>target resources. >> >>Compared to the existing browser profile, a JavaScript-disabled user, >>needs to perform an additional CONTINUE button click. >> >>From a systems point of view, it is important to note that >>the proposed >>scheme eliminates the configuration of both Pull URLs and PartnerIDs. >>This is BTW also the case with my other proposal, the opaque "bearer" >>object that though requires more network activity. The opaque >>stuff does >>*not* need JavaScript to work if this really is an important factor. >> >>Press-stop on HTTP POST redirects: After reading further on this >>subject it seems to be as follows: Redirects generate HTTP 302 but >>clients interprete HTTP 302 as HTTP 303 to cope with "current >>practice". >>I.e. a *lot* of code out there depends on a broken RFC!!! As >>my suggestion apparently does as well. Or actually, the most >>current RFC mentions this fact and suggests no counter-measures. >> >>thanx, >>Anders >> >>----- Original Message ----- >>From: "Mishra, Prateek" <pmishra@netegrity.com> >>To: "'Anders Rundgren'" <anders.rundgren@telia.com>; >><security-services@lists.oasis-open.org> >>Sent: Friday, August 03, 2001 00:42 >>Subject: RE: Update: Contributed doc. browser bindings incl. >>Shibboleth >> >> >>With the elimination of the Javascript step, we >>know have the following steps: >> >>(1) User accesses a link at the source site >>(2) source site serves up an HTML page containing a form >>(3) User clicks on a form SUBMIT button and arrives >>at the destination site >>(4) The destination site verifies that the included assertion >>is acceptable and presents a HTML page with a set of links to the user >>(5) The user selects the desired link and accesses the desired >>content. >> >> >>If you contrast this sequence with the current web browser >>profile you have: >> >>(1) User selects link at source site pointing to desired content >>at destination site (the TARGET) >>(2) User is redirected to a SAML artifact consumer URL at the >>destination >>site with a SAML artifact and target URL >>(3) SAML artifact consumer URL at destination site pulls assertion >>from source site and and validates it; >>(4)user is redirected to target URL. >> >>Notice that there is no user intervention in the current web >>browser profile after the initial selection of the target URL. >> >>- prateek >> >> >>>>-----Original Message----- >>>>From: Anders Rundgren [mailto:anders.rundgren@telia.com] >>>>Sent: Thursday, August 02, 2001 4:47 PM >>>>To: Mishra, Prateek; security-services@lists.oasis-open.org >>>>Subject: Re: Update: Contributed doc. browser bindings incl. >>>>Shibboleth >>>> >>>> >>>>Prateek, >>>>Although I share your concerns with the use of JavaScript, I believe >>>>this a since long lost case. There are *very* few that >>>>really turn off >>>>JavaScript as many sites simply do not work without it. >>>>There are AFAIK practically no proofs of successful attacks >>>>on browsing users although it has been explained how such >>>>attacks can be performed. >>>> >>>>Scipts in e-mail attachments that execute in the context of >>>>the user is an *entirely* different story. >>>> >>>>Anyway, "fat browser objects" do work (at the expense of >>>>an extra click by the user), even if JavaScript is disabled. >>>>I just did not include that part of the code as it looks a >>>>bit ugly :-) >>>> >>>>Anders >>>> >>>>----- Original Message ----- >>>>From: "Mishra, Prateek" <pmishra@netegrity.com> >>>>To: "'Anders Rundgren'" <anders.rundgren@telia.com>; >>>><security-services@lists.oasis-open.org> >>>>Sent: Thursday, August 02, 2001 22:13 >>>>Subject: RE: Update: Contributed doc. browser bindings incl. >>>>Shibboleth >>>> >>>> >>>>I would also view with great concern the use >>>>of Javascript. The security holes in the interaction >>>>between web browsers and Javascript are innumerable and continue >>>>to pop up every now and then. Take a look at >>>> >>>> http://polaris.umuc.edu/~mgaylor/jssecurity.html >>>> >>>>or indeed please search from google with the search pattern >>>> >>>>+security +javascript >>>> >>>> >>>>Certainly, many people would be concerned by >>>>its inclusion in a standard. I would argue that the >>>>SAML web browser profile should work with all scripting >>>>at the web browser turned off. >>>> >>>> >>>>- prateek >>>> >>>> >>>>>> >>>>>>> To what extent are they standard? >>>>>> >>>>>>It is an advanced use of existing standards including HTTP/S >>>>>>Base64, JavaScript, XML, PKI and HTML forms. >>>>>> >>>>>> >>>> >>>>------------------------------------------------------------------ >>>>To unsubscribe from this elist send a message with the single word >>>>"unsubscribe" in the body to: >>>>security-services-request@lists.oasis-open.org >>>> >> >>------------------------------------------------------------------ >>To unsubscribe from this elist send a message with the single word >>"unsubscribe" in the body to: >>security-services-request@lists.oasis-open.org >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC