Arkitekturoverblik

Denne side forklarer, hvordan løsningen er bygget. Den er skrevet til udviklere og andre tekniske læsere. Du får overblikket i to diagrammer. Det første viser løsningen udefra. Det andet zoomer ind på delene. Bagefter forklarer vi, hvordan vi holder kunders data adskilt, og hvor vi beskytter trafikken.

Siden nævner med vilje ikke servernavne, adresser, versioner eller andre interne detaljer. Det gør vi for at beskytte løsningen.

Fire platforme, én løsning

Løsningen findes i fire udgaver. De bygger på de samme byggesten.

  • MinForening er gratis. Den er til foreninger, klubber og NGO’er, også NGO-forbund. Et NGO-forbund kan købe modulet Forbund (beta) i Modulshop. Foreningerne deler hosting.
  • MinOrganisation er betalt. Den er til virksomheder, organisationer, forbund og større foreninger.
  • MitSamfund er først og fremmest en lokal kalender for et lokalsamfund. Den har også opgaver, booking og en shop.
  • White label giver en organisation sit eget domæne, sin egen webapp og sin egen mobilapp.

MinOrganisation bruger samme kode som MinForening. På MinOrganisation er data mere isoleret. White label kører på sin egen server hos Hetzner Cloud. Vi driver serveren. Vi kan flytte foreninger fra MinForening og organisationer fra MinOrganisation over til white label.

Vi slår modulerne til for hver forening eller organisation. De moduler, en forening eller organisation har købt i Modulshop, styrer den selv. En white label-kunde har ofte mere kontrol over modulerne og har ikke altid en modulshop. Det aftaler vi ud fra kundens behov. Derfor ser to foreninger ikke altid de samme menupunkter.

Niveau 1: Løsningen og omverdenen

Diagrammet viser det store billede: hvem der bruger løsningen, og hvilke andre systemer den udveksler data med. Selve løsningen er tegnet som én samlet boks. På næste niveau kigger vi ind i boksen.

Diagram: medlemmer, børn og unge, forældre og værger, foreningsadministratorer, forbundsadministratorer, offentlige besøgende og driftsmedarbejdere bruger løsningen. Løsningen er forbundet til eksterne kategorier: betalingsudbydere, regnskabssystemer, medlemssystemer, SMS- og push-tjenester, identitetsudbydere, offentlige tjenester, andre mailudbydere og AI-tjenester i skyen.

Personer øverst, løsningen i midten, andre systemer nederst. Pilene viser, hvem der bruger hvad.

Syv grupper af personer bruger løsningen:

  • Medlemmer deltager i aktiviteter og følger deres eget medlemskab.
  • Børn og unge bruger appen til deres egne aktiviteter.
  • Forældre og værger tilmelder og betaler for deres børn.
  • Foreningsadministratorer driver en forening med medlemmer, aktiviteter og betalinger.
  • Forbundsadministratorer har overblik over flere foreninger i et forbund.
  • Offentlige besøgende læser offentlig information og tilmelder sig.
  • Driftsmedarbejdere er vores egne medarbejdere, som driver platformen.

Løsningen taler med otte typer af eksterne systemer:

  • betalingsudbydere
  • regnskabssystemer
  • andre medlemssystemer
  • SMS- og push-tjenester
  • identitetsudbydere
  • offentlige tjenester
  • andre mailudbydere: modtagernes e-mailudbydere
  • AI-tjenester i skyen: Microsoft Azure OpenAI i en EU-region

For de fleste typer viser diagrammet ikke navne på leverandører.

Niveau 2: Et kig ind i maskinrummet

Det andet diagram åbner boksen. Det viser de dele, løsningen består af, og hvordan de taler sammen.

Diagram: løsningen består af beskyttelsesmur, en webapplikation, et API med baggrundsjobs, én database pr. kunde, mobilapps, en desktopapp, en AI-tjeneste, kalender og CMS, en driftsplatform, en egen mailserver og logning. Medlemmer og administratorer bruger webapp, mobilapp og desktopapp. Brugere og apps når webapplikationen, API og kalender gennem beskyttelsesmur. API'et bruger databaserne, AI-tjenesten, kalenderen, mailserveren og de eksterne tjenester, også AI-tjenester i skyen. Mailserveren sender e-mail til andre mailudbydere. AI-tjenesten bruger som standard egne Qwen-modeller. API'et sender foreningens aktiviteter til kalenderen, som henter sider og tjekker rettigheder hos API'et.

Diagrammet læses oppefra og ned. Personer øverst, så deres apps, så beskyttelsesmuren, så løsningens dele og andre systemer nederst.

Personerne bruger en app:

  • Webappen i browseren bruges af medlemmer og administratorer. Den kører på brugerens egen enhed.
  • Mobilapps på telefonen bruges af medlemmer, børn og unge, forældre og administratorer.
  • Desktopappen på pc’en har webappens sider og kan holde en lokal kopi af foreningens filer.
  • Hjemmesider i browseren: offentlige besøgende åbner foreningernes hjemmesider og kalendersider.

Browseren henter webappen fra webappens server. Alle foreninger i MinForening bruger den samme mobilapp, og hver forening har sit eget område i appen. MinOrganisation har sin egen app, som alle organisationer på MinOrganisation bruger. White label-kunder får deres egen app, deres eget API, deres egen database og deres egen server. Alle apps bygger på samme kode. Hent MinForening-appen i App Store eller Google Play. Hent MinOrganisation-appen i App Store eller Google Play.

Alle apps går gennem beskyttelsesmuren:

  • Beskyttelsesmur (en webapplikationsfirewall) står foran løsningens dele. Den stopper trafik, der ligner angreb, og sender resten videre.

Bag beskyttelsesmuren ligger løsningens dele:

  • Webappens server leverer webappens filer til browseren.
  • API med baggrundsjobs rummer forretningsreglerne. Appsene kalder det. Det holder kunder adskilt og udfører planlagt arbejde.
  • Kalender og CMS viser foreningernes hjemmesider og kalender for offentlige besøgende.
  • Databaser: hver kunde (tenant) har sin egen database. På MinForening deler foreningerne én database. Mere om det længere nede.
  • AI-tjenesten tager imod AI-forespørgsler fra API’et. Den bruger som standard vores egne Qwen-modeller.
  • Mailserveren: e-mail fra løsningen sendes fra vores egen mailserver direkte til modtagernes mailservere. Vores medarbejdere bruger Microsoft 365 til deres e-mail, og e-mail, som brugere skriver til os, går gennem Microsoft 365.
  • Logning er vores interne system til driftslogs.
  • Driftsplatformen er en intern styringsplatform, som vores medarbejdere betjener.

Kalenderen og CMS henter foreningens sider og indhold fra API’et og tjekker administratorers rettigheder hos det. API’et sender foreningens aktiviteter til kalenderen. API’et taler også med databaserne, AI-tjenesten og de eksterne systemer.

Driftsplatformen opretter og lukker kundeorganisationer og styrer deres abonnement og opsætning. Den hjælper os også med at overholde regler. Kunder logger aldrig ind på den. Logning samler tekniske logs fra platformens tjenester, så vores medarbejdere kan opdage og løse problemer.

Hosting: delt, isoleret og dedikeret

Vi tilbyder tre niveauer af hosting. Jo højere niveau, jo mere er adskilt fra andre kunder.

NiveauPlatformHvad betyder det
DeltMinForeningForeningerne deler servere og database. Hver forening er adskilt inde i databasen.
IsoleretMinOrganisationHver organisation har sin egen database og deler færre ressourcer med andre kunder.
DedikeretWhite labelOrganisationen har sin egen server hos Hetzner Cloud, sit eget domæne, sin egen webapp og sin egen mobilapp. Vi driver serveren. Nogle tjenester er stadig fælles for alle kunder: overvågning, vores beskyttelsesmur (WAF) og interne værktøjer til vores medarbejdere.

En forening eller organisation kan starte på et lavere niveau og senere flytte til white label.

Vores servere står hos Hetzner i Tyskland. Hetzner står for datacentrene, hardwaren, netværket og beskyttelsen mod DDoS-angreb. Vi driver selv serverne fra styresystemet og op. Se fordelingen i beslutning 0002. Vi har vores egne DNS-navneservere, ns1.wiiandi.dk og ns2.wiiandi.dk. De administreres af NordName.

Flere kunder i samme løsning

Løsningen er bygget til mange kunder på én gang. Vi bruger to begreber:

  • En tenant er den kunde, der har ansvaret for data. Hver tenant har sin egen database.
  • En forening ligger inde i en tenant. Én tenant kan rumme mange foreninger, afdelinger eller små organisationer.

Næsten alle data i databasen hører til en bestemt forening. API’et kontrollerer ved hver forespørgsel, at brugeren kun får de data, brugeren har ret til at se. En bruger kan godt være medlem af flere foreninger.

Sådan holder API'et kunderne adskiltEn forespørgsel fra appen går med brugerens adgangsnøgle gennem beskyttelsesmuren til API'et. API'et finder kunden ud fra webadressen og bruger kundens egen database. Derefter kontrollerer API'et brugerens rettigheder i den forening, som data hører til. Brugeren får kun de data, brugeren har ret til at se.Appensender forespørgselog adgangsnøgleBeskyttelsesmurenstopper trafik,der ligner angrebAPI'etfinder kundenud fra webadressenKundens databaseén databasepr. kundeRettighederneAPI'et tjekker demi den rigtige foreningSådan holder API'et kunderne adskiltEn forespørgsel fra appen går med brugerens adgangsnøgle gennem beskyttelsesmuren til API'et. API'et finder kunden ud fra webadressen og bruger kundens egen database. Derefter kontrollerer API'et brugerens rettigheder i den forening, som data hører til. Brugeren får kun de data, brugeren har ret til at se.Appensender forespørgsel og adgangsnøgleBeskyttelsesmurenstopper trafik, der ligner angrebAPI'etfinder kunden ud fra webadressenKundens databaseén database pr. kundeRettighederneAPI'et tjekker dem i den rigtige forening
Hver forespørgsel går gennem beskyttelsesmuren til API'et. API'et finder kunden og bruger kundens egen database. Derefter kontrollerer det brugerens rettigheder i den forening, som data hører til.

MinForening er selv én tenant med mange foreninger. En kunde på MinOrganisation eller white label har sin egen tenant og dermed sin egen database.

Hvor beskyttelsesmuren sidder

Webapplikationen, API’et og kalenderen ligger bag vores egen beskyttelsesmur. Beskyttelsesmuren er vores egen løsning, som vi selv har udviklet. Den kører i Hetzners datacentre i Tyskland foran app-serverne.

Beskyttelsesmuren blokerer kendte typer af angreb. Den begrænser antallet af forespørgsler. Den kan bede mistænkelige klienter bevise, at de ikke er robotter. Den kan også blokere efter land. Og den sørger for krypteret forbindelse med automatiske certifikater.

Vi offentliggør ikke regler, grænseværdier eller trafikkens vej. Det ville hjælpe en angriber.

AI i løsningen

Nogle funktioner bruger AI. Vi bruger to slags AI-udbydere i løsningen:

  • egne Qwen-sprogmodeller på vores egen infrastruktur
  • Microsoft Foundry OpenAI i en EU-region

Som standard bruger AI-funktionerne Qwen-modeller, som vi selv hoster. Microsoft Azure OpenAI i en EU-region bruges til nogle funktioner og som reserve. Claude fra Anthropic bruger vores udviklere kun internt, blandt andet til fejlrapporter. Vores supportteam bruger blandt andet Qwen-AI-modeller, som vi selv hoster, så vi kan hjælpe dig hurtigere.

Hvilken udbyder en funktion bruger, afhænger af funktionen. Siden om AI nævner udbyderen for hver funktion.

Læs videre