Bruker populering (ADC)

1 Innledning
2 Nøkkel info
3 Bakgrunn
4 Interessenter
5 Brukerhistorier og funksjoner
6 Systemer/tjenester
7 Samhandlingsmønster, Data og involverte API
8 Om involverte API
9 Tilgangsstyring og logging
10 Forretningsregler
11 Behandlingstid/responstid og volum

Innledning

Dette er en ny versjon av https://unit.atlassian.net/wiki/spaces/IPM/pages/2132017211 til det nye miljøet. Hovedappen er adc-app, som cacher hashet brukerdata (foreløpig kun fra LDAP) og genererer endringsmeldinger som sendes til adc-p360-app (https://unit.atlassian.net/wiki/spaces/IPM/pages/2661286002) og adc-ubw-app (https://unit.atlassian.net/wiki/spaces/IPM/pages/2661777537). De sistnevnte appene gjør de faktiske oppdateringene i endesystemene. ADC-app sørger for at meldingene sendes til riktig(e) app(er). Lenken til ADC-integrasjonen: .

Nøkkel info

Initiesering av flyt	Cron-job som kjører hver natt kl 2
Flyt møsnter	asynkron	Først kjøres en jobb for å finne alle endringer av brukere, så genereres det meldinger sendt via Kafka til hver tjenste.
Bruk av meldingskø	Ja, Kafka
Open API	Nei
IntArk	Ikke brukt

Bakgrunn

Denne tjenesten er en av de eldste vi har hatt kjørende. Målet har vært å synke over ansatt data (brukere) til de ulike administrative systemene. Da den gangen var ansatt data utilgjengelig via SAP, ble det bestemt å bruke Feide-ldapene som kilde.

Interessenter

Da brukerne av denne tjenesten er (og har vært en lang stund) UBW og Public360, er tjenesten Unit4 ERP og Dokumentasjonsforvaltning interessneter her.

Brukerhistorier og funksjoner

Når en ny ansatt registreres i Feide-ldap, vil en bruker opprettes automatisk for vedkommende basert på entitlements til brukeren.
UBW ansvarlig har mulighet til å definere en default-bruker som vil brukes som mal ved opprettelse av nye brukere.
P360 ansvarlige ved institusjonen kan velge om nye brukere skal opprettes som aktive/inaktive.
Institusjonen kan bestemme (for hver tjenste ubw/p360) om brukerne skal plukkes basert på entitlement, eller om alle brukerne skal opprettes.

Systemer/tjenester

Involverte systemer/tjenester er

Feide-ldap (ved hver institusjon),
Public360 og
UBW.

Brukerdata fra LDAP (kan utvides til flere kildesystemer), meldingskøer med Kafka. LDAP-data hentes vha. LDAP-service ().

Samhandlingsmønster, Data og involverte API

Prosessen består av 2 deler.

Først delen (adc-app) finner alle endringer siden sist kjøring. Dette gjøres ved å hente ut en full liste over alle aktive brukere fra Feide-ldapen til hver institusjon. En hash-verdi av brukerinformasjonen sjekkes mot databasen som inneholder hash-verdi av brukere hentet sist. På den måten vil tjenesten finne ut om brukere med endring. (og de som er nye eller ikke finnes lenger)
For hver endring funnet, sendes det en melding til P360 og/eller UBW køene basert på om institusjonen har den tjenesten (info om det har vi i vår config-db) og basert på entitlement på brukeren (hvis institusjonen har valgt å bruke entitlements, eller vil alle opprettes). Før meldingen sendes, utføres det en nytt kall til Feide-ldap for å hente ut brukerdata for brukeren som da legges til meldingen. Se under for komplett melding.
Merk at om brukeren er slettet, vil man ikke kunne hente ut noe bruker-data om vedkommende. Userdata vil da være null.

{
	"sourceType": “ldap”,
	"orgId": <orgId>,
	"userId": <feide-id>,
	"operationType": [create|delete|update],
	"userData": {
    "dn": "xxxx",
    "attributes": {
      "cn": [
        "xx"
      ],
      "eduPersonPrincipalName": [
        "xxxx"
      ],
      "givenName": [
        "xxxx"
      ],
      "mail": [
        "xxxx"
      ],
      "norEduPersonLIN": [
        "uis.no:employee:xxx",
        "uis.no:fsPerson:yyy"
      ],
      "sn": [
        "xxxx"
      ],
      "title": [
        "xxxxxxxx"
      ]
    }
  }
}

P360:
- For hver innkommende melding:
  - slår opp brukeren kontakt-personen (Get Contact Person). Om personen finnes fra før, oppdateres den (Update Contact Person), ellers opprettes. (Synchronize Contact Person) (merk sletting er en form for oppdatering da status oppdateres til false)
  - slår opp user (Get Users). Om den finnes, oppdateres den med eventuell ny status (Synchronize User)
UBW:
- For hver innkommende melding:
  - slår opp brukeren (GetUsers).
    - Om operasjonen er update/insert : Sjekk om en default-bruker er definert, hvis så, leses den (GetUsers). Så sjekkes om brukeren eksisterer, hvis ikke opprettes en ny bruker med eller uten default-data lest fra default brukeren (CreateUsers / CreateUsersWithDefaults). Så oppdateres brukeren (ModifyUsers). Oppdatering skjer selv om brukeren er nylig opprettet, fordi ikke alle verdier kan settes med engang. Dette gjelder spesielt ansatt nummer. Det som skjer, er at brukeren knyttes til den “resursen” med den gitte ansatt-nummer.
      UBW har nemlig en egen import som sørger for at alle ansatte ligger inni systemet som en “resource” med ansatt-nummer som id. Som del av oppdatering av brukeren, knytter vi brukeren til den ressursen.
    - Om operasjonen er delete : Om brukeren finnes, settes status til brukeren til “Terminated” (ChangeUserStatus)
Ved avsluttet operasjon, sendes det en kafka-melding tilbare til adc-app som oppdaterer status på operasjonen. På den måten vil den kunne følge med hvilke endringer er utført eller ikke.

Om involverte API

LDAP:
- List ut alle brukere
- Hent enkelt bruker
P360 :
- Get Contact Persons
- Get Users
- Synchronize Contact Person
- Synchronize User
UBW:
- GetUsers
- ModifyUsers
- ChangeUserStatus

Tilgangsstyring og logging

Ingen tilganstyring er nødvendig
Eventuelle tilgangstyring

Forretningsregler

Utlisting av alle aktive brukere fra LDAP, styres av et noen parametere tilpasset hver institusjon. Parametrene bestemmer hvilke brukere hentes (basert på en oppgitt filter)
Hvis antall slettede brukere er mer enn 10% av totalt antall brukere, vil prosessen stoppes opp. Det vil da kreve en manuell trigging for å kjøre videre.
UBW: Om ansatt-nummer er gitt i Ldap, vil det brukes for å knytte brukeren til ressursen.
UBW: Det er mulig å sette opp en default user. Default roller og andre parameter vil da hentes fra den brukeren ved opprettelse av nye brukere.

Behandlingstid/responstid og volum

Gjennomsnittelig, har det vært ca 230 brukerendringer funnet pr døgn (2023-07-11)
For hver bruker fra endringen oppdages til den behandles, tar det ca 2 sekunder.
Detaljert logging skjer i Humio