Klantinteractie-Servicesysteem / KISS-frontend

Repository for the KISS frontend developed with ICATT for Dimpact
Other
0 stars 4 forks source link

Inloggen #176

Closed sytskevanhasselt closed 1 year ago

sytskevanhasselt commented 2 years ago

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

sytskevanhasselt commented 2 years 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

rubenvdlinde commented 2 years ago

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/

sytskevanhasselt commented 2 years ago

Bevindingen

Zie document, bevinding SH02

Bevindingen_Sprint04_20220725SvH.docx

rjzondervan commented 2 years ago

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.

felixcicatt commented 2 years ago

@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.

felixcicatt commented 2 years ago

@sytskevanhasselt op kiss-dev werkt het uitloggen nu, dat kan je testen. Voor de ontwikkelaars is het wel fijn als Robert bovenstaande nog fixt.

sytskevanhasselt commented 1 year ago

Status = done