Re: Update: Contributed doc. browser bindings incl. Shibboleth

[Anders Rundgren <anders.rundgren@telia.com>]

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