Eleven eller medarbejderen skal være almindeligt medlem af skolens Entra-tenant. Private Microsoft-konti og B2B-gæster afvises.
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
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
Skolen oprettes på forhånd med sin kendte tenant-identifikator. Consent-callbacks kan ikke oprette eller whitelist'e en ny skole.
Licensperioden skal være aktiv, og den aktuelle DPA skal være underskrevet.
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.
Godkendelse sker i tre kontrollerede trin
Tilbagekaldelse
Skolens administrator kan tilbagekalde appens consent i Microsoft Entra. ATHENODE markerer derefter consent som manglende eller tilbagekaldt, og skolen er ikke længere klar til skoleadgang.
Nyt samtykke
Kontakt ATHENODE for et nyt tenant-specifikt link. Administratoren godkender igen, og ATHENODE gentager serververifikationen. Et gammelt eller udløbet link kan ikke genbruges.
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
- Skolen modtager den aktuelle DPA til gennemgang.
- Spørgsmål og eventuelle bilag afklares med ATHENODE.
- Den godkendte version underskrives og registreres.
- 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ål | Endpoint | Bemærkning |
|---|---|---|
| Microsoft-login | login.microsoftonline.com | Systembrowser, tokens og tenant-specifikt admin-consent |
| Microsoft Graph | graph.microsoft.com | Grundlæggende brugerprofil og valgte OneNote-data |
| ATHENODE auth | api.athenode.dk | Identitet, readiness, seat og aktivering. Bekræftes i skolens onboardingmateriale |
| Elevens valgte AI-udbyder | Udbyderens dokumenterede API-værtsnavn | For 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.
- Afklar pilotSkole, tenant-GUID, kontaktperson og forventet antal seats.
- Gennemgå DPADen aktuelle aftale og relevante bilag behandles af skolen.
- Godkend consentATHENODE sender link, administrator godkender, og scopes verificeres.
- Aktivér pilotLicens og pilotseats åbnes, og et elevlogin kontrolleres.
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.