[Se-leg-ref] Kommentarer på uppdaterad dokumentation

Hej igen Fredrik! Tack för att ni förtydligar era tankegångar och att vi får vara med och hjälpa till :-) Vi var nog lite otydliga. Vårt förslag baseras inte mest på säkerhet, snarare enkelhet och "spec-compliance". Precis som steg 5-13 är en del av autenticeringen av end-user, dvs utanför scopet av OIDC, så skulle också steg 13.8 och 13.9 vara en del av autenticeringen. Genom att införa requesten i steg 13.8/13.9 så möjliggör vi för OPn att verkligen svara med en redirect i steg 14 (enligt kapitel 3.1.2.5 i OIDC). Detta, tror vi, skulle göra se-leg-flödet lättare att förstå och lättare att koppla till OIDC-specen. För slutanvändaren märks ingen skillnad. return them Angående "redirect_uri" så säger också OAuth 2, kapitel 1.7: "...While the examples in this specification show the use of the HTTP 302 status code, any other method available *via the user-agent* to accomplish this redirection *is **allowed* and is considered to be an implementation detail.". Med vårt förslag (steg 13.8 och 13.9) så uppfylls kravet till fullo. polla Fullt möjligt ja, men vi förstår inte fördelen? Varken spec-compliance, säkerhet/infrastruktur eller enkelhet i flöde och integration. Mvh /Magnus och Anders tors 29 sep. 2016 kl 15:56 skrev Fredrik Thulin <fredrik at thulin.net>: > On torsdag 29 september 2016 kl. 13:23:07 CEST Magnus Hoflin wrote: > > Hej, > > > > Tack för den uppdaterade dokumentationen, > > https://github.com/SUNET/se-leg-docs/blob/master/oidc_flow.md, den har > > underlättat mycket för förståelsen! > > Vi har huvudsakligen två kommentarer: > > > > Kommentar 1: > > Det fattas en/två pilar direkt innan steg 14. Man kan ju inte skicka en > > HTTP-response från ingenstans utan det måste ju initieras av en > > HTTP-request. > > Hej > > Steg 14 i diagramet är ett OIDC Authentication Response, det är inte ett > HTTP > response. Det levereras till RP:n som en HTTP Request ställd till den > redirect_uri som gäller för RP:n. > > > Att införa en HTTP-request skulle också lösa det problem vi > > tidigare har lyft, nämligen att man inte vill ha en OP-initierad > > backend-kanal till IdPn eftersom en sån kanal skulle bara ställa till med > > FW-problem etc. Vi föreslår två nya steg precis innan steg 14, kalla dem > > 13.8 och 13.9: > > > > - 13.8: Pil "User" -> "RP/IdP": Användaren indikerar mot IdPn att > > han/hon är klar med identifieringen på t.ex. biblioteket. Detta kan > bl.a. > > ske när användaren "klickar bort" QR-koden på mobilen. > > - 13.9: Pil "RP/IdP" -> "OP": IdPn begär ett Authentication response. > > Du har anfört säkerhetsskäl för att inte släppa in HTTP requests från OP:n > till RP:n. Min förståelse av OIDC Authorization flow är att det inte funkar > så. > > https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth > > 3.1.2.5. Successful Authentication Response > When using the Authorization Code Flow, the Authorization Response MUST > return > them > as query parameters to the redirect_uri ... > > Det borde vara fullt möjligt för dig att bygga en egen kö-nod utanför din > brandvägg som tar emot dessa svar från OP till RP och sedan låter dig polla > svaren från innanför din brandvägg. Jag säger inte att jag tycker det > verkar > vara en bra idé, men givet dina prioriteringar så kanske det är den bästa > lösningen. > > > Kommentar 2: > > Har vi förstått det rätt att det 'nonce' som IdPn genererar i steg 4 är > > samma 'nonce' som också används som QR-kod? Hela den här processen kan > > sägas baseras på en identifieringstransaktion som OPn ansvarar för. Vi > > tycker det känns avigt att IdPn ska generera transaktionsIDt (idag > > "noncet") för den transaktion som OPn ansvarar för. Vi förelår att *OPn* > > genererar ett 'transaktionsID' som returneras i steg 5 och som sen > används > > i QR-koden. Detta transaktionsID skickas med i steg 13.8 och 13.9 ovan, > så > > att OPn vet vilken transaktion den ska returnera identiteten för. Detta > är > > möjligt p.g.a. att användaren är inloggad via steg 1-2. > > Om man fortfarande vill använda ett nonce i det syfte specen anger, dvs > som > > skydd mot replay-attacker, så kan man förstås göra det också. Men > > transaktionsIDt bör inte blandas ihop med replay-skydd-noncet. > > Och om det är vi som har feltolkat flödet så är det nog bra om ni > > uppdaterar så att det inte heter nonce på båda ställena. > > > > Dessutom: > > Om ni vill förtydliga ert sekvensdiagram ytterligare så vore det jättebra > > ifall ni kopplade de olika stegen mot de steg som är listade i kapitel > > 3.1.1 i OpenID-specen. > > Tack för synpunkterna. > > /Fredrik > > -- Magnus Hoflin Co-founder, CTO +46 709-27 83 28 magnus at diglias.com *Diglias* J A Pripps gata 2 421 32 Västra Frölunda www.diglias.com