Autentisering & Autorisasjon
Autentiseringsløsningen for folk.knowit.no gjøres mot Azure Entra ID (Tidl. Azure AD) og AWS Cognito. Alle Knowit sine ansatte ligger inne som brukere i Azure og flyttingen av autentiseringen til Azure ble gjort for å åpne opp applikasjonen for de andre selskapene i Knowit.
Applikasjonen åpnes for brukere per organisasjon i Azure. Det vil si at de som har ansvaret for Knowits Azure Subscription i Sverige må legge til gruppen med brukere til et gitt selskap for applikasjonen. Dette kan gjøres ved å sende inn en forespørsel til Knowit Internal Helpdesk.
Det ligger en egen User Pool for applikasjonen i Cognito, som ikke må forveksles med den gamle som også har en app integrasjon for Folk, men med autentisering mot Google. For å sette opp User Poolen ble både den gamle User Pool og User Poolen for Kompetanse-applikasjonen brukt som mal og til referanse.
[Env] AWS konto (id) - user pool name:
- [DEV] knowit-dataplattform-dev (723164513951) - dev-folk-user-pool
- [PROD] knowit-dataplattform-produksjon (349886516100) - TBA
En Federated identity provider sign-in ble satt opp for Azure. Dette ble gjort i samarbeid med Helpdesken i Sverige som måtte sende over en Metadata document endpoint URL, som de får under registreringen av applikasjonen i Azure.
Under listen med App clients ble det lagt til en ny applikasjon for Folk. Denne bruker en Hosted UI for innloggingen og autentiseringen mot Azure. Her blir AzureAD fra Federated identity provider sign-in brukt med redirects tilbake til applikasjonen. Det var ikke noe behov for noen spesifikke redirect URLer, som et resultat av at Hosted UI brukes.
For hvert selskap som skal bruke applikasjonen, så må det finnes en gruppe i user poolen. Det er strenge regler for hvordan navnet for hvert selskap skal være. Kan være aktuelt å se på eksempler for andre selskap i en annen user pool.
Eksempler på noen selskap:
- knowitobjectnet - Knowit Objectnet
- knowitexposlo - Knowit Experience Oslo
- knowitexpbergen - Knowit Experience Bergen
- knowitamende - Knowit Amende
Grunnen til at dette er viktig er fordi det finnes en preSignUpTrigger (folkPresignupTrigger-[env]) for Folk som legger inn brukere til riktig selskap basert på det navnet, og navnet er lagret og hentet fra en database (Se NB under).
NB! For øyeblikket (04.06.2024) er det kun mulig for ansatte i Knowit Objectnet å logge inn å få en bruker i Cognito User Pool. Databasen med selskap brukes ikke og knowitobjectnet brukes hardkodet i Lambda-triggeren. Dette kommer i neste steget med å åpne opp applikasjonen for andre selskap.
User Pool gruppene skal brukes til å tilganstyre hvilke data som kommer inn i applikasjonen. Når flere selskap er implementert vil det være user pool gruppen som bestemmer hvilke data som skal brukes for den innloggede brukeren.
Tidligere var autentiseringsløsningen gjort opp mot Google. Dette ble endret i perioden 04.2024 - 06.2024.
folk.knowit.no er en intern nettside som kun var tilgjengelig for Knowit Objectnet med innlogging via Google. Fordi Knowit konsernet og deres ansatte stort sett forholder seg til Azure Entra ID (tidl. Azure AD), var det et ønske om å endre innloggingen til Folk til å bli mer som innloggingen til applikasjonen Kompetanse. Tanken her er å åpne opp Folk slik at den blir som Kompetanse, hvor hvert Knowit selskap har tilgang til å bruke nettsiden med sine egne data for sine ansatte.
Dette er skrevet til hjelp dersom noe tilsvarende skal settes opp for andre apper.
Kodeendringene bestod av å fjerne endepunkter som ble brukt til å lagre Bearer token og all håndtering relatert til innlogging og pålogging basert på diverse tokens lagret i browser cachen/storages.
- Byttet ut gammel autentiseringsflow gjennom OpenID-klient til Amplify. Wrappet appen i en <Authenticator.Provider>
- Tar i bruk imports fra Amplify, i.e. fetchAuthSession() og signInWithRedirect() til å håndtere innlogging, utlogging og access token.
- Fjernet client_secret som en env variabel som ikke lenger er i bruk med den nye client appen i user poolen.
Den første delen av arbeidet gikk ut på å lage en ny user pool. For å gjøre det enkelt ble navnet [env]-folk-user-pool bruker. Som referanse ble user poolen hvor Kompetanse-applikasjonen i produksjon ligger brukt. Den forholdt seg til User name som var case sensitive, og derfor ble det valgt i den nye user poolen. SAML ble brukt for å sette opp Federated sign-in options med Azure. Dette kunne skippes inntil man hadde en Metadata Document, via filopplasting eller URL, fra Azure registreringen av applikasjonen.
Når det gjelder passord var det bare å bytte til custom og fjerne alle passordkrav.
MFA er også ikke nødvendig, og det skulle være mulig for brukerne å bruke Glemt passord.
Det var viktig å huke bort for selvregistrering.
Registrering av nye brukere skal kun skje av preSignUpTriggeren for user poolen eller en administrator.
Utover det var det å legge til noen egendefinerte attributer. I første omgang var det kun nødvendig med company.
Domain type kunne bruke den tidligere applikasjonen sitt egendefinerte domene, men dette valget måtte være på plass til før registreringen av applikasjonen i Azure, fordi URLen brukes til å sette opp SAML konfigurasjonen i Azure. Når det ble satt opp for dev-miljøet, var ikke dette kjent til å begynne med, så konfigurasjonen av SAML ble gjort med Cognito domenet i stedet. For user poolen til Folk i produksjon vil det egendefinerte domenet blit sendt til Helpdesken i Sverige.
Applikasjonen kunne fint være en public client uten en client secret.
Callback- og Sign-out URLene trengte bare å være URLen til nettsiden. Eksempelet her har også med localhost for lokal utvikling.
Autentiseringsflowen blir via CUSTOM_AUTH og USER_SRP_AUTH og Identity provideren blir satt til å være den man lagde for Azure Entra ID.
Neste del ble å fullføre konfigurasjonen av Federated identity provideren ved å registrere appen i Azure. Denne biten blir devlis håndtert parallelt med oppsettet av user poolen.
NB! Det kan være nødvendig å sette noen verdier under oppsettet av user poolen til en verdi som senere blir endret. Dette kan bl.a. være identity provideren under oppsettet av app klienten. Den kan midlertidig settes til å være Cognito sin defaulte.
En mal ble brukt til å sende forespørsel om å registrering av applikasjonen i Azure:
- Application Name: Knowit Folk
- Scope: email openid profile
- Redirect URIs:
-
- Local:* http://localhost:3000/
-
- Production:* https://folk.knowit.no/
- Which users should have access: Everyone in Knowit Objectnet except for externals/service-users/disabled users
- Type Flow: Code Flow
- Type App: Web app
- What kind of application is it: A page to lookup employees and customers. It is possible to see at which customers employees works for, employee competence and motivations, work experience and other information about an employee, as well as an organizational structure map of Knowit Objectnet
I tillegg til denne infoen må Identifier (Entity ID) og Assertion Consumer Service URL sendes med for SAML konfigurasjonen på Azure-siden.
- Identifier (Entity ID) følger formelen urn:amazon:cognito:sp:[user-pool-id]. (urn:amazon:cognito:sp:eu-central-1_j53koCuOX)
- Assertion Consumer Service URL følger formelen [user-pool-domain]/saml2/idpresponse. (https://dev-folk-user-pool.auth.eu-central-1.amazoncognito.com/saml2/idpresponse)
Når appen er registrert og man har mottatt Metadata Document URLen eller filen, så kan fullføre de siste stegene med å lage user poolen f. eks. oppdatere identity provideren til å være den fullførte versjonen av Federated Identity Provider Sign-In med Metadata dokumentet.
Det finnes parametere som brukes og settes i AWS Parameter store (som kan søkes etter i AWS) relatert til Folk applikasjonen. De meste aktuelle å se på er:
- [env]/folk-webapp/CLIENT_ID
- [env]/folk-webapp/DATAPLATTFORM_API_URL
- [env]/folk-webapp/DATAPLATTFORM_AUTH_URL
Disse må stemme overens med ClientId for Folk i App integrasjonen og Cognito/Custom domain i user poolen. API URLen vil muligens være satt opp fra før av, men den må stemme overens med APIet som brukes relatert til proxy funksjonen.
Det må lages en Lambda function som trigges når en brukes under autentisering av nye brukere.
Triggeren bruker attributer for brukeren som kommer fra autentiseringen mot Azure. Her er blant e-post og selskap, som brukes til å sjekke om brukeren eksisterer fra før av og hvilket selskap de tilhører. Det gjøres mer også og koden som brukes kan eksempelvis sees her for dev.
Denne måtte lages fra scratch og ha riktig Role og Resource-based policy statements.
En ny rolle måtte lages for denne triggeren slik at det var mulig for funksjonen å kjøre spesifikke metoder.
- Lage en ny rolle
- Velge AWS Service som Trusted entity type og Lambda som Use case
- For Permissions må AWSLambdaBasicExecutionRole velges
- Lage en Customer inline permission for metoder som brukes i Lambda funksjonen. Den består av
{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "cognito-idp:AdminCreateUser", "cognito-idp:AdminSetUserPassword", "cognito-idp:AdminAddUserToGroup", "cognito-idp:AdminLinkProviderForUser", "cognito-idp:AdminUpdateUserAttributes", "cognito-idp:ListUsers" ], "Resource": "arn:aws:cognito-idp:*:*:userpool/*" } ] }
Ved behov kan man se hvordan det er gjort for dev her.
Denne Lambda funksjonen skal allerede eksistere, men for dev måtte den lages på nytt. Den er basert på server-koden i prosjektet og blir configurert via serverless.yml filen i prosjektet.
Det dukket opp noen problemstillinger underveis med å sette opp proxy funksjonen fra scratch som kan være verdt å nevne:
NB! Dette er ikke nødvendigvis noe som må gjøres, men kan være til hjelp under feilsøking.
- Pipelinen til prosjektet feilet fordi Lambda funksjonen ikke eksisterte. Derfor måtte det lages en Lambda funksjon med riktig navn og så måtte Deploy - Dev Force for å synce metoden og oppdatere den til å bli riktig.
- Under _Resource-based policy statements for proxyen manglet det en * helt på slutten av AWS:SourceArn.
- Fjernet env variabel fra serverless.yml. Kan også være en årsak til at pipelinen feilet og at Deploy - Dev Force måtte kjøres.