[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Update: Contributed doc. browser bindings incl. Shibboleth
Prateek, The entire javascript solution: <HTML> <BODY BGCOLOR="#FFFFFF" Onload="javascript:document.forms[0].submit ()"> <FORM METHOD="POST" ACTION="Destination-URL"> <NOSCRIPT> <CENTER><H2>Your browser is JavaScript-disabled!</H2> <H3>Click on the button below to manually continue the login</H3> <INPUT TYPE="SUBMIT" VALUE="Continue"></CENTER> </NOSCRIPT> <INPUT TYPE="HIDDEN" NAME="SAML" VALUE="88676765565GTE34"> </FORM> </BODY> </HTML> >>>(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? >>I would not make this mandatory as it would both complicate >>things, and there are probably not that many "secret" assertions. >Hmmmm. I disagree. As we are building a security protocol this feels >like a pretty big issue to me. My first cut would be that >confidentiality should be required in this context. Otherwise, >I can watch assertions fly by me and learn quite a lot >about the AP and RP and what sort of information they plan >to exchange. I don't think that security is an issue in this case. At least if we are taking technical security in the sense that a user could fake data in some way by looking on it. To be able to do that you must crack signatures keys etc. That the protocol and verbs are exposed is not a problem if we are not dealing with a system based on "security by obscurity". I therefore still prefer that encryption should depend on if the information exchanged between the AA and RP is secret for the user. My *guess* is that this is seldom the case. At least in the B2B-systems, like OBI, that we work with, it never is. I.e. employers (AAs) do not (in such systems) exchange data about their employees with external business partners (RPs) that the employees are not aware of. Actually these assertions are often not even carrying the employee's names. >>>(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. <snip> >The point here is that the form (with the assertion >contained within it) is now present within the local >state of the browser. People >can use the "back" button and access it and re-post >it to the destinaton site. Browsers >are used in the public arena (kiosks, airports), >not just in private offices. People may complete >a short transaction and then walk away from the >machine. I have two comments on this. 1. Any browser-based system that caches any kind of assertion-data will allow a "back" button replay. I.e. the only solution are one-time assertions which we aleady have [as an option] in our system using "fat browser objects". 2. If someone logins to the AA and leaves the browser open they are in trouble anyway, independent on what kind of system they are using. Anders
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC