[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: REPEATED: F2F input to bindings
The F2F #4 is over, but the issues remain. Why not take a shot at this or do you have a problem with the issues? Or with me? :-) :-) POST seems to finally (I proposed this in January... http://lists.oasis-open.org/archives/security-services/200101/msg00007.html) have landed at least. If the issues are insignificant, please let me know why. /a.r. ----- Original Message ----- From: "Anders Rundgren" <anders.rundgren@telia.com> To: "OASIS SAML" <security-services@lists.oasis-open.org>; "Hallam-Baker, Phillip" <pbaker@verisign.com>; "Tim Moses" <tim.moses@entrust.com>; "Mishra, Prateek" <pmishra@netegrity.com>; <rlmorgan@washington.edu> Sent: Monday, August 27, 2001 10:40 Subject: F2F input to bindings Hi Guys! I would have loved to come to the F2F but can't make it. I would though very much appreciate a comment at least on point #2, #3 and #4 below as they are sort of fundamental. Regarding #4: clock-sync independence is another thing that PUSH [at least could] introduce. I would like to see some more discussions on scaling, statefulness, configuration, user-friendliness, ASP, and reliability issues. All these factor are within SAML scope IMHO. Anders ----- Original Message ----- From: "Anders Rundgren" <anders.rundgren@telia.com> To: "Mishra, Prateek" <pmishra@netegrity.com>; "OASIS SAML" <security-services@lists.oasis-open.org> Cc: <security-bindings@lists.oasis-open.org> Sent: Friday, August 24, 2001 11:47 Subject: Re: draft-sstc-bindings-05 Prateek et al, Here are some comments to the bindings-05 draft browser profile(s). 1. The initial GET used in all profiles specifies (by example) that the query string contains TARGET etc. IMHO the initial GET should not be restricted/specified in any way as it is an entirely internal thing of the source site. I.e. GET could equally well point to an URL with a local database index in the query string etc. It could AFAIK equally well be a POSTed form (that we have recently found out is GET-compatible with respect to redirects). 2. An observation (for what it is worth): - In PUSH the source-site is authenticated before the dest-site - In PULL the dest-site is authenticated before the source-site - In POSTed form only the source-site is authenticated I sort of prefer the second *principle* as it is more in-line with authentication in general and is a must for Shibboleth-like uses. 3. The s.c. distinguished assertion consumer URL could without any performance or security implications be fully dynamic in the PUSH profile (to require source sites to configure *two* destination URLs is IMO a bit over the edge). In the same way, PartnerIDs are redundant for all profiles except for PULL. 4. IMHO only the PUSH profile is user-friendly, as a broken URL or rejected request will be detected first-hand by the user's own site/server (possibly automatically alerting the IS-department, and giving the user a nice/appropriate error-message), while the other profiles leave the user with the problem. 5. That POSTed forms implicate stateful destination-servers is IMHO not absolutely necessary as there are workarounds: -A short-lived assertion like 60 seconds, makes replay "possible" but still "unlikely" to be performed by any other but the original user. -A session-cookie should be able to hold the last assertions used at a particular site to hamper replay. Although replay protection is highly recommended, I still wonder if it should be a MUST as this could be considered as a policy-decision rather than a technical ditto. Regards Anders ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC