For skoler

Skolelogin med fuldt overblik

Her kan IT, ledelse og DPO se, hvad skolen godkender, og hvilke data ATHENODE ikke modtager.

Skolen er klar, når alle fire forhold er opfyldt

Tenant verificeret Licens aktiv DPA underskrevet Admin-consent verificeret

Eleven bruger skolens eksisterende Microsoft-konto

ATHENODE åbner Microsoft-login i computerens systembrowser. Eleven indtaster sin adgangskode hos Microsoft. ATHENODE ser, modtager eller gemmer aldrig adgangskoden.

Standardflowet er Authorization Code med PKCE S256 og et loopback-kald på 127.0.0.1. Hvis browser, firewall eller loopback giver problemer, kan eleven vælge en engangskode som fallback. Personligt Microsoft-login er et separat flow og blandes ikke sammen med skolelogin.

App- og udgiveroplysninger

Skolen godkender én organisationsbaseret multitenant Microsoft Entra-app. Den er afgrænset til konti i organisationer og kan ikke bruges med private Microsoft-konti.

Planlagt appnavn
ATHENODE Skolelogin
Udgiver
ATHENODE, udgiververifikation: TBD
Microsoft client-id
TBD - indsættes efter den endelige appregistrering
Kontotype
Accounts in any organizational directory
Klienttype
Offentlig desktop-klient med loopback-redirect
Tenantmodel
Multitenant, men kun forhåndsregistrerede og verificerede skole-tenants kan aktiveres

Ingen hemmelighed i appen: En serverbeskyttet credential bruges kun af ATHENODEs server til at kontrollere admin-consent. Den distribueres aldrig med desktop-appen.

Krav til tenant

En whitelist alene aktiverer ikke skolen

Organisationskonto

Eleven eller medarbejderen skal være almindeligt medlem af skolens Entra-tenant. Private Microsoft-konti og B2B-gæster afvises.

Verificeret tenant-GUID

Skolen oprettes på forhånd med sin kendte tenant-identifikator. Consent-callbacks kan ikke oprette eller whitelist'e en ny skole.

Aktiv aftale

Licensperioden skal være aktiv, og den aktuelle DPA skal være underskrevet.

Verificeret consent

Det godkendte scope-sæt skal være verificeret af serveren, før nye elever kan få et seat.

Adgang bindes til kombinationen af skolens tenant-id (tid) og Microsoft-brugerens objekt-id (oid). Navn og mail bruges ikke som adgangsnøgle eller til automatisk kontolinking.

Præcis de tilladelser skolen godkender

ATHENODEs delegerede Microsoft Graph-tilladelser er User.Read og Notes.Read. Loginprotokollen bruger desuden openid og profile; de er OIDC-protokolscopes og giver ikke yderligere adgang til Microsoft Graph-data.

User.Read

Bekræfter brugerens organisationsidentitet

Bruges ved første skolelogin til grundlæggende profil og til at knytte login til den verificerede tenant og brugeridentitet.

Notes.Read

Læser de OneNote-noter eleven vælger

Anmodes først på elevens enhed, når eleven vælger OneNote som kilde. Tilladelsen giver læseadgang, ikke skrive- eller sletteadgang.

Skoleadministratoren godkender begge dele på forhånd i admin-consent. Elevens første login anmoder kun om User.Read. Notes.Read bruges først ved et aktivt OneNote-valg.

Serveren gemmer identitet og aktivering, ikke elevens arbejde

ATHENODE-serveren gemmer

  • Tenant-id og Microsoft objekt-id for skoleidentiteten
  • Valgfri visnings- og kontaktinformation
  • Seat-, licens-, DPA- og consent-status
  • Login- og aktiveringstidspunkter samt nødvendige auditposter

ATHENODE-serveren gemmer ikke

  • OneNote-noter eller lokale dokumenter
  • Elevens spørgsmål eller AI-svar
  • AI-udbyderens API-nøgle
  • Elevens Microsoft-adgangskode eller rå login-tokens

DPA-proces

Den gældende databehandleraftale skal være underskrevet

  1. Skolen modtager den aktuelle DPA til gennemgang.
  2. Spørgsmål og eventuelle bilag afklares med ATHENODE.
  3. Den godkendte version underskrives og registreres.
  4. Ny version kræver fornyet godkendelse, før readiness kan opretholdes.

Netværksallowlist

Domæner der skal kunne nås over HTTPS

Den endelige allowlist bekræftes under onboarding, fordi elevens valgte AI-udbyder kan ændre behovet. Følgende kategorier skal som minimum vurderes:

FormålEndpointBemærkning
Microsoft-loginlogin.microsoftonline.comSystembrowser, tokens og tenant-specifikt admin-consent
Microsoft Graphgraph.microsoft.comGrundlæggende brugerprofil og valgte OneNote-data
ATHENODE authapi.athenode.dkIdentitet, readiness, seat og aktivering. Bekræftes i skolens onboardingmateriale
Elevens valgte AI-udbyderUdbyderens dokumenterede API-værtsnavnFor eksempel API-værten for den eksterne udbyder, eleven vælger, eller en lokal Ollama-adresse

Proxy og TLS-inspektion

Trafik til Microsoft, Microsoft Graph, ATHENODE og den valgte AI-udbyder skal kunne gennemføre moderne TLS uden omskrivning, der bryder certifikatvalidering eller tokenudveksling. Hvis skolen bruger TLS-inspektion, anbefales en undtagelse for de godkendte værter.

Loopback på elevens computer

Systembrowser-flowet returnerer til http://127.0.0.1:<dynamisk-port> på samme computer. Proxy eller endepunktssikkerhed må ikke omdirigere eller blokere dette lokale tilbagekald. Engangskode kan bruges som fallback ved lokale begrænsninger.

Udbyderafhængige endepunkter

ATHENODE-serveren modtager ikke elevens AI-nøgle. Desktop-appen kontakter den valgte udbyder direkte. Lokal Ollama bruger en lokal adresse, mens eksterne udbydere kræver deres egne API-værter på skolens allowlist.

Forventet onboarding og support

En ukompliceret onboarding kan normalt gennemføres inden for få arbejdsdage, når tenant-GUID, kontaktperson, DPA-underskriver og Entra-administrator er tilgængelige. Tidsplanen afhænger især af skolens DPA-gennemgang og interne godkendelser.

  1. Afklar pilotSkole, tenant-GUID, kontaktperson og forventet antal seats.
  2. Gennemgå DPADen aktuelle aftale og relevante bilag behandles af skolen.
  3. Godkend consentATHENODE sender link, administrator godkender, og scopes verificeres.
  4. Aktivér pilotLicens og pilotseats åbnes, og et elevlogin kontrolleres.
Support og skoleonboarding kontakt@athenode.dk

Ved tekniske fejl bør henvendelsen indeholde skolens navn, tidspunkt, platform og den viste correlation-id. Send aldrig adgangskoder, Microsoft-tokens eller AI-nøgler.