11:54 a.m.
On måndag 3 oktober 2016 kl. 08:25:55 CEST Magnus Hoflin wrote:
Hej igen,
Bra invändning Rebecka, vi håller med, det höll inte riktigt som vi ritade
det. Vi ville inte ändra mer än nödvändigt i er lösning men det blev inte
ett resultat som kan sägas följa specen. Och vi håller 100% med er om att
det behöver bli en lösning som följer spec, annars finns det ju ingen poäng
med att basera sig på en standard öht.
Vi tycker er lösning på det stora hela känns bra. Vi har dock fortfarande
en "gut feeling" om att det föreslagna sättet att skicka responset inte är
best practice, kanske t.o.m. fel. Vi vill också poängtera att vi inte ältar
det här för att djävlas utan för att vi, precis som ni, är måna om att
komma fram till bästa möjliga lösning.
Så vi gör ett nytt försök: OIDC bygger ju på OAuth2. Vår tolkning är att
tillämpliga skall-krav i OAuth2 gäller, så länge inte OIDC "overridar" det.
Med det sagt hävdar vi att det inte är OK att utesluta user-agent när man
skickar AuthenticationRequest och AuthenticationResponse. Se kap 3 (översta
stycket med punktlistorna) i OAuth2 (
https://tools.ietf.org/html/rfc6749#section-3) Man kan också läsa kap 1.7
i samma spec för en nyansering av det (
https://tools.ietf.org/html/rfc6749#section-1.7) Nyckelorden är "via the
user-agent". Det finns alltså t.ex. en anledning till att det heter
"redirect_uri" och inte "response_uri". Vi känner inte till att OIDC
(eller
OAuth2) någoLnstans lättar på det kravet, gör ni?
Hej
Rebecka är den riktiga experten på OIDC, så jag lämnar åt henne att kommentera
detta.
Vi har ritat en ny skiss som vi bifogat. Notera där
att vi använder oss av
noncet på det sätt ni föreslog, men som vi hade en invändning mot. Här blev
det tvunget att göra på ert sätt och vår invändning var mer av karaktären
"om det går att undvika" snarare än "absolut inte!!", och i det
läget
kändes response-skickandet mycket mer angeläget.
Genom att ta med user-agent i skickandet av AuthenticationRequest och
AuthenticationResponse så försvinner per automatik den delen i lösningen
som vår "gut feeling" har vänt sig emot. Men, vi känner också att ni kanske
har uteslutit user-agent av en bra anledning och att vi inte har förstått
hela use-caset? Om så är fallet får ni gärna förklara så att vi får hela
bilden klar för oss.
Jag har tittat lite på ert diagram och tror att det vore fullt möjligt att
bygga se-leg så, men några observationer:
1) Användarens browser skulle studsa runt mellan diglias.com och se-leg.se i
det du beskriver som "loop". Möjligen går det att gömma i bakgrunden så att
användarna slipper se (och oroas av) det.
2) Genom att slutförd se-leg vetting inte konstateras förän användaren
återvänder till IdP:n (dvs. exempelvis diglias.com) så får inte IdP:n
tidsmässig möjlighet för ex. eget beslutsfattande involverande en människa
efter se-leg vetting men innan användaren får status X eller Y i ert system.
När ni, enligt nuvarande implementation får ett callback-anrop till er
redirect_uri direkt från se-leg:s OP så har ni mycket större möjlighet till
egna kontroller, value add som att skicka ett SMS till användaren och
informera om att det är klart, eller vad ni nu skulle kunna tänkas vilja göra.
3) I er skiss sker ett anrop till er redirect_uri från användarens browser
istället för från OP:n, men ett anrop sker likväl. Er redirect_uri måste
således vara nåbar för inkommande HTTP-anslutningar, eller hur? Jag antar att
den dessutom kommer vara nåbar från hela internet, medans den i nuvarande
implementation skulle kunna begränsas till att bara vara nåbar från några
kända ändpunkter hos se-leg.
/Fredrik