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?
står det ju att:
"If the resource owner grants the access request, the authorization
server issues an authorization code and delivers it to the client by
adding the following parameters to the query component of the
redirection URI"
Där authorization server är OP och client är RP. Jag kan inte heller se
någon annan anledning till att att RPn (enligt spec) måste registrera
en redirect_uri om den inte skulle användas för att initiera
kommunikation från OPn.
Sen tycker jag också att det är en feature att OPn hör av sig till RPn
när resultatet av autentiseringen är klar. Det är betyder att OPn kan
göra extra kontroller av den information användaren och ombudet har
uppgivit (som tar okänt lång tid) innan resultatet skickas till RPn.
Annars måste ju alla RPs polla OPn för uppdateringar för alla pågånde
autentiseringar.
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:
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
--
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
Mvh
--
Johan Lundberg
NORDUnet A/S
Tulegatan 11
113 53 Stockholm
+46730714375