10:39 p.m.
Jag hänger inte riktigt med. Var någonstans står det
att steg 14 är en
302?
Det finns exemplifierat här:
https://openid.net/specs/openid-connect-core-1_0.html#AuthResponse. Detta
exempel har ni själva också använt som exempel här:
https://github.com/SUNET/se-leg-docs/blob/master/oidc_flow.md om du tittar
på steg 14 i den textuella beskrivningen, inte i bilden.
Som vi har implementerat detta, helt och hållet i
enlighet med
OIDC-specen enligt vad jag förstår, så är steg 14 en HTTP request från
OP
till RP.
Håller inte med! Jag har inte heller särskilt mycket erfarenhet av OIDC,
men tycker att både
https://openid.net/specs/openid-connect-core-1_0.html#AuthResponse och dess
motsvarighet i Oauth, https://tools.ietf.org/html/rfc6749#section-4.1.2 pekar
på att det är klient/RP-initierad kommunikation som gäller, d.v.s. att i
kommunikationen mellan IdP och OP är det IdPn som skickar requests och OPn
responses. Inte att både IdP och OP skickar HttpRequests vid olika
tillfällen.
Om jag ställer motsvarande fråga till dig: Var i OIDC-specen hittar du stöd
för att skicka en HTTP-request från OPn till RPn?
Och om båda varianterna skulle vara tillåtna enligt spec, på vilket sätt
skulle OP->RP-request göra lösningen bättre?
Vilket är problemet du försöker lösa egentligen?
Följande anledningar, in order of importance:
1. Att jag inte tycker föreslagen lösning följer specen. (om det inte vore
för detta skulle vi inte fortsätta älta detta)
2. HttpRequesten från OP->RP gör hela flödet/lösningen mer komplicerad,
helt i onödan.
3. Det leder till att alla RP/IdP kommer behöva sätta upp servrar helt i
onödan. Det introducerar både onödiga säkerhetsrisker och onödig
FW-administration. Det här var det skäl vi angav först, redan på mötet i
våras, men inte det viktigaste.
Om jag förstår det rätt vill du dessutom tillföra
några out-of-band HTTP
request/responses som inte alls finns med i OIDC-standarden.
Nej. Jämför med en vanlig SAML-autenticering baserad på redirect: Sista
HTTP-requesten i autenticeringen (t.ex. username/password POST) triggar det
HTTP-response som redirectar AuthnResponset från IdP, via user-agent, till
RPn. HTTP-requesten (t.ex. username/password POST) är ju out-of-scope för
SAML-specen, men en viktig del i flödet. Det är precis samma sak jag vill
åstadkomma här och jag har svårt att se att OIDC skulle vilja göra det på
ett annat sätt.
Och jag är medveten om att IdPn agerar "user-agent". Förslaget är att
redirecten går från OPn (steg 14), via IdPn, tillbaka (steg 15) till den
resurs hos OPn som sen levererar ID-tokenet. Dvs det är en redirect OP ->
IdP -> OP, inte via användaren.
Det är förstås ni som sätter lösningen, men så länge vi inte förstår hur
lösningen är tänkt att fungera och mappa mot den standard ni säger er följa
så kommer vi inte kunna vara tysta. Antingen får ni övertyga oss genom att
visa var i specen det står att man kan/bör skicka HTTP requests OP->RP,
eller så får ni väl bara bortse från våra förslag.
Trevlig kväll!
/Magnus
tors 29 sep. 2016 kl 20:06 skrev Fredrik Thulin <fredrik at thulin.net>:
On torsdag 29 september 2016 kl. 17:53:07 CEST Magnus
Hoflin wrote:
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
Ja, den 302 som ni redan har listat som exempel
på steg 14 och som listas
som exempel i OIDC-specen.
Jag hänger inte riktigt med. Var någonstans står det att steg 14 är en 302?
Den kan ju inte skickas som ett
HTTP-response/redirect utan att den har föregåtts av HTTP-request.
Som vi har implementerat detta, helt och hållet i enlighet med OIDC-specen
enligt vad jag förstår, så är steg 14 en HTTP request från OP till RP.
Vi var nog lite otydliga. Vårt förslag baseras
inte mest på säkerhet,
snarare enkelhet och "spec-compliance".
Du har vid två tillfällen tagit upp detta som ett problem utifrån hur du
vill
konfigurera dina brandväggar, att du inte vill tillåta inkommande
connections
från OP till din RP. Nu säger du dock att det inte handlar om säkerhet utan
för att det ska "skulle göra se-leg-flödet lättare att förstå och lättare
att
koppla till OIDC-specen". Vilket är problemet du försöker lösa egentligen?
Är det ett substantiellt problem eller lägger vi mer tid och kraft på den
här
diskussionen än vad problemet egentligen rättfärdigar?
Jag kan inte säga att jag ännu har sett något som blir lättare eller
bättre av
den föreslagna ändringen som jag tycker känns mest som ett försök att få
authentication flödet att se ut som att användarens webbläsare var
inblandad,
när det i själva verket är en server hos er som är client och en server hos
se-leg som är server. Om jag förstår det rätt vill du dessutom tillföra
några
out-of-band HTTP request/responses som inte alls finns med i
OIDC-standarden,
vilket således leder till en svensk lösning snarare än en standardbaserad
lösning.
Jag vill dock öppet säga att jag inte har någon erfarenhet av just OIDC
sedan
tidigare så jag hoppas att få höra fler röster i det här samtalet.
Trevlig kväll
/Fredrik
--