Page Comparison

...

Innledning

...

Dette er en ny versjon av /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 (/wiki/spaces/IPM/pages/2661286002) og adc-ubw-app (/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: Autorisasjonsdatacache (ADC).

...

Bakgrunn

• Litt om grunnen til integrasjonen. Hva for en behov dekkes av integrasjonen.

Interessenter

• Hvem er ansvarlig for datakommunikasjonen? Hvem bestilte dette og betaler for at utvekslingenpågår?

Brukerhistorie (gjerne sekvensdiagram) ?

Hvis vi har noen

Systemer/tjenester

• Detaljert liste av alle innvolverte systemer/tjenester Hva utveksler data? Fra hvor / Til hvor?

• Hvilken kø-mekanisme brukes evt.?

• Om Int-ark komponenter er brukt og eventuelt hvilke deler

Data

• Hvilke data utveksles?  Alle attributter som utveksles?

Samhandlingsmønster

• Hva driver utvekslingen? Request eller Push

• Er utvekslingen synkron eller asynkron?

Om involverte API

• Brukte API endepunkter

Tilgangsstyring og logging

• Hva logges?

• Eventuelle tilgangstyring

Forretningsregler

• Forretningslogikken i integrasjonen. Feks. Bare dokumenter med status X leses etter Y antall dager osv …

Behandlingstid/responstid og volum

• Hva er antallet meldinger pr. døgn i denne forbindelsen (Min, Avg, Max)

Feilhåndtering, konsekvenser av feil og overordnet risikoanalyse

• Hva skjer ved overload i kø?

• Hva skjer med ufullstendinge meldinger?

• Inneholder meldingene personopplysninger?

• Noe om viktige feil/situasjoner som må passes ekstra på (som kan ha stor konsekvens). F.eks : Oppgavene som aldri vil publiseres, eller Oppgaver som ikke skal publiseres, publiseres.

Flytdiagram ?

Nøkkel info

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

• UBW.

Brukerdata fra LDAP (kan utvides til flere kildesystemer), meldingskøer med MeldingQ. LDAP-data hentes vha. LDAP-service (/wiki/spaces/IPM/pages/2610102276).

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)

  • Her er en JSON-schema som kan brukes til å validere strukturen i meldingen som blir videresendt til UBW og/eller P360:

    Code Block

    { "$schema": "http://json-schema.org/draft-07/schema#", "type": "object", "properties": { "sourceType": { "type": "string" }, "orgId": { "type": "string" }, "userId": { "type": "string", "format": "email" }, "operationType": { "type": "string", "enum": ["insert", "update", "delete"] }, "userData": { "type": "object", "properties": { "dn": { "type": "string" }, "attributes": { "type": "object", "properties": { "cn": { "type": "array", "items": { "type": "string" } }, "eduPersonPrincipalName": { "type": "array", "items": { "type": "string", "format": "email" } }, "givenName": { "type": "array", "items": { "type": "string" } }, "l": { "type": "array", "items": { "type": "string" } }, "mail": { "type": "array", "items": { "type": "string", "format": "email" } }, "mobile": { "type": "array", "items": { "type": "string", "pattern": "^\\+\\d{8,15}$" } }, "norEduPersonLIN": { "type": "array", "items": { "type": "string" } }, "postalAddress": { "type": "array", "items": { "type": "string" } }, "sn": { "type": "array", "items": { "type": "string" } }, "title": { "type": "array", "items": { "type": "string" } } }, "required": ["cn", "eduPersonPrincipalName", "givenName", "sn"] } }, "required": ["dn", "attributes"] }, "removedEntitlements": { "type": "array", "items": { "type": "string" } } }, "required": ["sourceType", "orgId", "userId", "operationType", "userData"] }

  • Forklaring:

    • sourceType, orgId, userId, og operationType er påkrevd felt med spesifikke typer.

    • operationType er begrenset til verdiene "insert", "update", eller "delete".

    • userData inneholder dn og attributes, som har egne valideringsregler.

    • attributes inkluderer flerdimensjonale arrays for felt som navn, e-post, mobilnummer osv. Format- og mønstervalidatorer sikrer korrekt struktur.

    • removedEntitlements er en valgfri liste med strenger.

• 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 MeldingQ-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