Hej på er,
Som vi sa på mötet så kommer här URLerna till OPn och vetting-"appen"
samt de uppgifter vi behöver för att registrera er i OPn.
Vad ni behöver, provider config:
issuer: https://front.se-leg.se
Vetting-app:
https://front.se-leg.se/vetting-app/
Vad vi behöver från er, client config:
client id: valfritt id (vi använder dev.eduid.se)
client secret: valfri hemlig sträng
redirect uri: URL till er authorization endpoint
Vi kan även generera client id och secret till er men då får ni gärna
skicka vilken gpg-nyckel ni vill ha svaret krypterat med. Vill ni hitta
på eget id och secret så kryptera gärna svaret med min medföljande
nyckel.
Fråga gärna om jag har använt otydliga termer.
Mvh
--
Johan Lundberg
NORDUnet A/S
Tulegatan 11
113 53 Stockholm
+46730714375
Hej!
Utvecklarmiljön (https://github.com/SUNET/se-leg-developer) är nu uppdaterad och fungerar på Mac OS X.
Den kräver “Docker for Mac” som är en beta-version och kräver en invite:
1. Registrera er på https://beta.docker.com/, så kommer det en invite per mail (kan dröja ett tag, så gör det gärna så fort som möjligt).
2. När ni fått en invite, ladda ner Docker for Mac och installera det.
3. Följ instruktionerna i repo’t för utvecklarmiljön: https://github.com/SUNET/se-leg-developer/blob/master/README.md
Med 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
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. 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.
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.
Mvh
/Magnus och Anders, Diglias
--
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
