Closed sytskevanhasselt closed 1 year ago
Ik heb gisteren kort het vraagstuk over bearer-token vs http only cookie voorgelegd bij architect Martijn. Het leek hem een beslissing voor een meer technische architect, maar hij was ermee akkoord dat wij zelf de beslissing nemen over de beste aanpak. Daarnaast was zijn insteek: doe het zoals OpenFormulieren het doet. @hannekevanderhorst weet bij wie we dat kunnen navragen
Vraag willen we hier ook meteen de SSO op de wordpress installatie op mee nemen? In dat geval moeten we op wordpress onderstaande plugin installeren en deze koppelen aan DEex.
https://wordpress.org/plugins/miniorange-openid-connect-client/
Nieuwe uitlogmethode: Er kan een API call gedaan worden op kissdevelopment-dimpact.commonground.nu/api/users/logut, daarmee wordt de cookie unset waarmee je uitgelogd raakt. Dit is dus een API call die onder water moet gebeuren, maar voorkomt gekkigheid met de redirects op de gateway.
@rjzondervan op zich werkt dat, alleen moet de set-cookie header SameSite=none bevatten, anders werkt het niet bij local development. Idealiter is dat configurabel op dezelfde manier als bij het inloggen.
@sytskevanhasselt op kiss-dev werkt het uitloggen nu, dat kan je testen. Voor de ontwikkelaars is het wel fijn als Robert bovenstaande nog fixt.
Status = done
Toelichting
Als KCM wil ik dat ik, op basis van mijn 'account' automatisch ingelogd zijn op KISS (SSO).
bespreken: hoe integreert dit met de frontend? welke (oath) flow wordt er gevolgd. waar leeft het token?
Voorgestelde oplossingsrichting conduction: front-end houdt jwt token vast en stuurt dit als bearer-token met elk request mee. Vraag aan architecten: is dit veilig genoeg? Todo uitzoeken of het ook mogelijk is om de gateway het token te laten ontvangen en in een http only cookie op de browser te bewaren. half uur aan besteden wo. anders gaan we voorlopig door met de eest optie en leggen we het tzt voor aan de architecten. Deze tweede optie volgt het authorization-code-flow proces (https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow) en is geschikt omdat de gateway het enige endpoint is voor de front-end. Alle api's worden via de gateway aangesproken.
voor elk pagina eerst een check: ben je al ingelogd, anders een call naar /me om te bepalen of je ingelogd bent. of kan de gateway als proxy voor de website staan. dan hoeft in de website/front-end nooit gechekt te worden of je wel ingelogd bent
wat zijn de implicaties voor de ontwikkelomgeving bij beide oplossingsrichtingen? vanuit de ontwikkelomgeving communiceren met de gateway op de dev omgeving. dus die moet cookies/tokens vanaf localhost accepteren. op demodam zou hij alleen requests vanaf hetzelfde domein moeten accepteren. dit zou dus instelbaar moeten zijn per omgeving.
nb. we werken dus alleen met accounts die rechstreeks in dex onderhouden worden. als we het sso principe willen domenstreren, dan moet dimpact een AD beschkibaar stellen
Acceptatiecriteria
Functionele teststappen
Taken Conduction
Taken ICATT
blocked voor ICATT:wachten op inrichting conduction
Taken DIMPACT
Discussie