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

Ja, den 302 som ni redan har listat som exempel på steg 14 och som listas som exempel i OIDC-specen. Den kan ju inte skickas som ett HTTP-response/redirect utan att den har föregåtts av HTTP-request. Men jag känner att det blir lite förvirrat och lätt att blanda ihop OIDC request/response med HTTP request/response. Så för att vara tydlig: https://docs.google.com/drawings/d/1kApdmkDxIv_Y6k2OSCNq13DheJ3vhZe6C8pW7nZ… I 13.9 skickas nonce/transaktionsID med, så att OPn vet vilken transaktion den ska skicka AuthenticationResponse för i steg 14. Mvh /Magnus tors 29 sep. 2016 kl 19:21 skrev Fredrik Thulin <fredrik at thulin.net>: 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

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. 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? 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. 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>: 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

Verkar som mitt tidigare svar inte kommit till listan, försöker igen: (tl;dr: Johan har hittat det viktigaste stycket, se hans mail.) Hej Magnus, Jag ska försöka adressera dina funderingar angående spec-compliance: OpenID Connect fungerar i vanliga fall (för autentisering på webben, som är det vanligast use case’t i dagsläget) såhär: 1. Användaren surfar till rp.example.com och klickar på logga in 2. RP’n gör ett authentication request genom att redirect’a användaren i webbläsaren till op.example.com/authenticate 3. Användaren autentiserar sig på något sätt (out-of-band för OIDC spec’en) 4. OP’n skickar ett authentication request genom att redirect’a användaren i webbläsaren till rp.example.com/redirect_uri Det viktiga, men osynliga, faktum är att det finns en webbläsare (”user agent” i specarna) som sköter punkt-till-punkt kommunikationen. Så på HTTP request nivå händer egentligen följande (lite förenklat/förkortat): 1. GET rp.example.com, sen GET rp.example.com/login 2. RP’n svarar med 302 och en Location header som innehåller OP’s authentication request ‘authorization_endpoint’, “Location: op.example.com/authenticate?<auth req params>” a. Här kommer webbläsaren in och följer redirect’en, GET op.example.com/authenticate 3. Användaren autentiserar sig (kommer antagligen inkludera lite fler HTTP requests, men dessa är utanför spec’en) 4. OP’n svarar till slut med en redirect: 302 och en Location header som innehåller authentication response RP’s redirect_uri: “Location: rp.example.com/redirect_uri?<auth resp params>” a. Här kommer webbläsaren in och följer redirect’en, GET rp.example.com/redirect_uri Så även i det vanliga webb-flödet av OIDC, måste RP’n vara publikt åtkomlig för HTTP request till det man publicerar som redirect_uri för att 4a ska fungera. I grunden är OIDC ett asynkront protokoll på samma sätt SAML; man får *inte* tillbaka authentication response som ett HTTP response på authentication request’ets HTTP request. Saken med SE-Leg är att vi inte har någon webbläsare/user agent. Så vi låter helt enkelt OP’n och RP’n kommunicera direkt med varandra. Alltså har vi klippt bort både 2a (authentication request ska skickas som en POST till authorization_endpoint i SE-Leg) och 4a (OP gör GET direkt på redirect_uri i SE-Leg). Jag ser inget i specen som skulle förhindra detta use case. Ert förslag är ett litet avsteg från OIDC-flödet eftersom det antar att RP’n är den som initierar authentication response. Det är OP’n som gör det, genom att skicka svaret till RP’s redirect_uri. Först senare i flödet, för token_endpoint och userinfo_endpoint, sker det direkta HTTP request/response som RP’n initierar. Hoppas det blev lite klarare. Vänliga hälsningar, --- Rebecka Gulliksson ICT Services and System Development (ITS) Umeå University SE-901 87 Umeå, Sweden rebecka.gulliksson at umu.se www.its.umu.se On 30/09/16 10:51, "se-leg-ref on behalf of Johan Lundberg" <se-leg-ref-bounces at lists.sunet.se on behalf of lundberg at nordu.net> wrote: Ska börja med att jag också är ny på det här med OIDC men i https://too ls.ietf.org/html/rfc6749#section-4.1.2 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.

Hej igen, Jag är lite osäker på hur du menar med symmetrisk vs. asymmetrisk i det här fallet. Som jag ser det så har vi bara tagit bort mellanhanden (användarens webbläsare), och inte vänt på flödet. Vi har valt att implementera ett flöde som så långt som möjligt följer det vanligaste OpenID Connect flödet. Detta har vi valt eftersom de inom den arbetsgruppen redan genomfört ett gediget säkerhetsarbete (som dessutom förbättrats efter att externa forskargrupper studerat protokollet närmare). Förutom säkerhet är det som tidigare nämnts en fråga av att försöka få en så standardiserad lösning som möjligt. Jag förstår er synpunkt om att vilja undvika en server för RP’n, men samtidigt ser jag inte hur det är möjligt att ta bort användandet av redirect_uri utan att göra ett stort avsteg från OIDC och hamna i en helt custom lösning. Vänliga hälsningar, --- Rebecka Gulliksson ICT Services and System Development (ITS) Umeå University SE-901 87 Umeå, Sweden rebecka.gulliksson at umu.se www.its.umu.se From: se-leg-ref <se-leg-ref-bounces at lists.sunet.se> on behalf of Magnus Hoflin <magnus at diglias.com> Date: Friday 30 September 2016 13:38 To: "se-leg-ref at lists.sunet.se" <se-leg-ref at lists.sunet.se> Subject: Re: [Se-leg-ref] Kommentarer på uppdaterad dokumentation Hej igen, Johan/Rebecka: bra kommentar att identifieringen kanske dröjer och att det är anledningen att ni har valt att göra som ni gör. Att OIDC är asynkront, och att HTTP är synkront, och hur de mappas till varandra är vi naturligtvis på det klara med. Men på en högre nivå är OIDC normalt ändå "symmetriskt". Problemet som vi ser det är att ni i steg 14 vänder på det och låter OPn agera HTTP-requestor, och gör lösningen asymmetrisk, och att det är någonting man vill undvika i den här typen av lösningar. Enklare lösningar som är symmetriska är enklare att följa, bygga och underhålla, det är därför vi fortsätter argumentera. Bifogat finns ett förslag på en sån symmetrisk lösning, som bara är ett par justeringar på ert förslag. Kontentan är att i valet mellan: * att undvika pollning RP->OP och * att undvika att öppna upp en server hos RPn så väljer vi att undvika att öppna upp en server hos RPn, alla dar i veckan. Men det vore förstås intressant att höra vad de andra IdPerna säger? (Och som sagt tidigare, vi anser att vårt förslag i allra högsta grad är i linje med specen. Vi kan argumentera mer för det om ni vill.) Mvh /Anders och Magnus

On måndag 3 oktober 2016 kl. 08:25:55 CEST Magnus Hoflin wrote: Hej Rebecka är den riktiga experten på OIDC, så jag lämnar åt henne att kommentera detta. 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

Hej, Bra kommentarer, ska försöka bemöta dem punkt för punkt. 1) Angående loopen så är det något som görs när det finns anledning. Dvs när användaren accessar RP:n eller någon annan händelse, så det är inte en konstant pollande lösning. Rent visuellt för användaren behöver det knappt märkas, man byter server under en sekund och är sedan tillbaka hos RP. Eftersom vi troligtvis inte producerat något content under round-trip RP-OP-RP så lär inte browsern uppdatera sig förrän man är tillbaka hos RP. Det skulle ju även kunna vara ett javascript-API med ett AJAX-anrop vilket skulle förenkla ännu mer. 2) Eftersom loopen görs först när användaren accessar RP och lägg då till att bibliotekarien säger "Gå in på RP imorgon bitti ska detta vara klart". Då ges tid för OP att bli klar eftersom OPs process-tid måste vara ganska förutsägbar och det kommer inte behövas mer än en (1) pollning. Och en pollning som händer en gång är inte en pollning utan bara en vanlig request. Man skulle kunna ha en back-end kanal enligt det ursprungliga sekvensdiagrammet, men då inte som en del av OIdC, utan som ett tillägg till standardtjänsten för de som vill ha en event-driven back-end kanal. Om RP också har en backend-processing-tid av någon anledning så är detta upp till RP att lösa. 3) Det är en stor skillnad på ett back-end-anrop machine-to-machine vs en inloggad användare med en session. Backend: * IP filtrering är nödvändigt * Lösningen behöver vara elastisk och redundant och lätt kunna skalas och lastbalancera åt båda håll, både på se-leg sidan och RP. * Om se-leg behöver lägga upp fler maskiner med flera IP måste det lätt gå att distribuera och enabla de nya IP:t hos samtliga RP:n. Vi har varit med i projekt med väldigt stora företag där detta varit omöjligt. * Pss om RP behöver skalas upp eller byta IP/DNS. * Vissa Paas leverentörer är ju super-elastiska där även IP-numret är dynamiska och kan bytas. Så IP filtrering kan vara ett riktigt elände när det börjar skala. * Authentisering av OP * PKI antar vi? Administrationskostnader tillkommer och lite komplicerat för vissa. * Lösenord, fast det känns inte som ett seriöst alternativ... * Om en RP använder sig av flera asynkrona lösningar blir det väldigt konfigurationsintensivt. Dvs det skalar dåligt. frontend: * Auth response kommer in som en redirect till en inloggad session, svårspoofad * Elastisk lösning från befintlig RP infrastruktur Johan och alla andra RP:s: vad har ni för åsikter? Om det det inte framgått tidigare så passar en front-end lösning mycket bättre i vårt koncept och är ett starkt önskemål. Vi har plöjt ned nog med tid på detta de senaste dagarna. Ska diskussionen fortsätta tror jag vi behöver sätta oss och prata över skype eller i samma rum. mvh Anders & Magnus mån 3 okt. 2016 kl 10:54 skrev Fredrik Thulin <fredrik at thulin.net>: