Dette APIet er for å tilgjengeliggjøre kundedata (fra Dynamics/CRM) og ansattdata (fra Azure AD/GraphMs) i form av en enkel API mest tenkt til intern-bruk i SIKT.
API’et er tilgjengelig via Gravitee : sikt-intern-api
Initiesering av flyt | Initiert av API bruker | Passiv API |
---|---|---|
Flyt mønster | Synkrone, stateless |
|
Bruk av meldingskø | ingen |
|
Open API | Åpen for intern bruk |
|
IntArk | Bruker Gravitee | APIet er tilgjengelig via Gravitee |
Det er et ønske om å tilgjengeliggjøre data i et intern-API, som inneholder kundedata fra CRM (MS Dynamics) og ansattdata fra Azure AD (Azure Graph API). Disse APIene er ganske komplekse, så vi forenkler bruk av de og samler de i ett API (Sikt intern API). I tillegg hentes noe av organisasjonsstrukturen fra LDAP (seksjoner).
Andreas Åkre Solberg ved Team datadrevet Sikt (orden i eget hus)
Data hentes fra CRM, Azure AD og LDAP (Ldap-service). Gravitee i IntArk og Feide JWT token brukes.
Azure Graph API:
https://learn.microsoft.com/en-us/graph/use-the-api
https://learn.microsoft.com/en-us/graph/api/overview?view=graph-rest-1.0
https://learn.microsoft.com/en-us/graph/sdks/choose-authentication-providers?tabs=Java
https://learn.microsoft.com/en-us/graph/query-parameters?tabs=http
Azure Dynamics API:
Ldap-service
/wiki/spaces/IPM/pages/2610102276
I syntaks (query parameter) ligner de to Azure APIene, men det er forskjell på nøyaktig hva de støtter.
Standard logging til Humio som viser bruk av API’et og eventuelle feil situasjoner
Tilgangstyring:
Via API nøkler via Gravitee
Feide (Feide JWT token)
-
På nåværende tidspunkt er ikke tjenesten i aktiv bruk i noe særlig grad.
Hva skjer ved overload i kø?
Hva skjer med ufullstendige 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.
Department/seksjon er kun et tekstfelt i Azure AD. Derfor hentes seksjoner fra LDAP.
Støtter per nå BÅDE Gravitee API key OG Feide JWT token
Tanken er etterhvert at JWT tokenet skal inneholde EduPrincipalName slik at vi kan sjekke om personen som har autentisert seg er i Sikt (avhengig av scope).
https://docs.feide.no/data_sharing/jwt_token_exchange.html
Unittester finnes på mule-workspacen i Postman, i mappen Sikt API app/Unit-tester.