RE: Web-browser Binding Vulnerabilities + "Cures"

["Orchard, David" <dorchard@jamcracker.com>]

Right, passport requires gets (posts don't do well in redirects) and the
multi-redirect method - Site A redirects to asserter with requested URL in
it, asserter verifies, then redirects to requested URL and adds assertion
info.  

Note this doesn't work very well with wireless devices as cookies on
wireless are problem.  Also many companies - rightly or wrongly - disable
the use of cookies.

Jamcracker's approach for SSO in the ASP ecosystem is to use a back-channel
communication between the Site A and the asserter.  The assertion travels on
the back-channel with a reference being in the URL on the browser.  Note
that we do the launching of apps from our portal - the first use case.

Cheers,
Dave

> -----Original Message-----
> From: Anders Rundgren [mailto:anders.rundgren@telia.com]
> Sent: Tuesday, January 16, 2001 1:34 PM
> To: S2ML; Orchard, David
> Subject: Re: Web-browser Binding Vulnerabilities + "Cures"
> 
> 
> David,
> I can't say I have tested a lot of browsers but so far as I 
> know this method
> is used by Passport.com which is the SSO of Hotmail.com
> /Anders
> 
> ----- Original Message ----- 
> From: "Orchard, David" <dorchard@jamcracker.com>
> To: <"SMTP:sach"@sap.com'
> Sent: Tuesday, January 16, 2001 21:24
> Subject: RE: Web-browser Binding Vulnerabilities + "Cures"
> 
> 
> > And how do you do cross domain cookies so that domain A can 
> send info to
> > Domain B?  We haven't found many browsers that support this 
> lack of cookie
> > privacy.
> > 
> > Dave Orchard
> > XML Architect
> > Jamcracker Inc.,    14000 Homestead Dr., Sunnyvale, CA 94086
> > p: 408.864.5118     f: 408.725.4310
> > 
> > Named to Red Herring's list of 100 Most Important Companies:
> > www.redherring.com/mag/issue79/herring100/jamcracker.html
> > 
> > 
> > > -----Original Message-----
> > > From: Paulus, Sachar [mailto:sachar.paulus@sap.com]
> > > Sent: Monday, January 15, 2001 11:25 PM
> > > To: 'Anders Rundgren'; S2ML
> > > Subject: RE: Web-browser Binding Vulnerabilities + "Cures"
> > > 
> > > 
> > > That is what SAP experienced too. Therefore, our SSO solution uses
> > > (digitally signed user info in) cookies....
> > > 
> > > -----Original Message-----
> > > From: Anders Rundgren [mailto:anders.rundgren@telia.com]
> > > Sent: Freitag, 12. Januar 2001 13:30
> > > To: S2ML
> > > Subject: Web-browser Binding Vulnerabilities + "Cures"
> > > 
> > > 
> > > The following does IMO apply to many schemes including S2ML:
> > > 
> > > The use of references to assertions etc. in the form of 
> URLs which are
> > > usually given to an
> > > authenticated client by a credential issuer using an HTTP 301 
> > > (redirect) has
> > > at least one
> > > problem: A credential consumer cannot easily determine if it 
> > > is the original
> > > client that
> > > handed over the URL containing such a reference. A simple 
> > > browser URL window
> > > snooper program could "snatch" such tokens and transport them 
> > > to somebody
> > > else.
> > > In spite of secure https transports.
> > > 
> > > The only "cures" I can think of are putting the critical data 
> > > in a cookie
> > > [sorry :-( ], which requires a
> > > fairly deep browser hack [open source would make it trivial 
> > > though :-) ] to
> > > snatch, and IP bindings.
> > > The latter is not universal due to proxies (all clients on 
> > > the same proxy
> > > looks like one IP for the credential
> > > consumer) etc. but it does improve the binding a bit.
> > > 
> > > Note: I don't insist that the current binding scheme should 
> > > be changed, this
> > > is simply "information".
> > > 
> > > Anders
> > >
>