Tekniska krav
1. Inledning
För att använda de digitala tjänster och AI-tjänster som finns inom Kommuna behöver kommunen kunna ansluta till dessa genom federativ inloggning. Den standard som används för autentisering inom Kommuna är OpenID Connect (OIDC). I denna dokumentation beskrivs de krav som finns för anslutning på en generell nivå. En enskild digital tjänst kan ha särskilda krav, men uppfylls de som beskrivs här är det generellt inga problem att använda alla tjänster inom Kommuna.
2. Översikt av federativ inloggning
2.1 Grundprinciper
Den federativa inloggningsmodellen bygger på följande principer:
- Varje kommun styr självständigt vilka autentiseringsmetoder som ska gälla för sina medarbetare.
- De delade tjänsterna inom Kommuna lagrar inga lösenord eller autentiseringsuppgifter.
- Användare autentiseras alltid via sin hemkommuns identitetstjänst.
- OIDC används som standardprotokoll för all federativ kommunikation.
2.2 Rollfördelning
Integrationen bygger på den standardiserade rollfördelningen inom OIDC-ekosystemet:
| Roll |
OIDC-terminologi |
Aktör |
| Tjänsteleverantör |
Relying Party (RP) |
Tjänster inom Kommuna |
| Identitetsleverantör |
OpenID Provider (OP) |
Respektive kommun |
| Slutanvändare |
End-User |
Kommunens medarbetare |
3. Krav på anslutande kommun
3.1 Rollen som OpenID Provider
För att ansluta till tjänster inom Kommuna krävs att kommunen agerar som OpenID Provider (OP) i OIDC-federationen. Detta innebär att kommunen ansvarar för:
- Autentisering av sina medarbetare enligt kommunens egen säkerhetspolicy.
- Utfärdande av ID-tokens och access tokens till tjänsterna (Relying Party).
- Tillhandahållande av användarinformation (claims) enligt överenskommet format.
- Val och konfiguration av autentiseringsmetoder (t.ex. lösenord, MFA, e-legitimation).
3.2 Befintliga plattformar med OIDC-stöd
De flesta kommuner har redan infrastruktur på plats som kan agera OpenID Provider. Vanligt förekommande plattformar inom kommunal sektor inkluderar:
| Plattform |
Kommentar |
| Microsoft Entra ID |
Tidigare Azure AD. Inbyggt OIDC-stöd. Vanlig i Microsoft 365-miljöer. |
| Nexus HAG |
Hybrid Access Gateway. Stödjer OIDC, SAML och andra federationsprotokoll. |
| MobilityGuard OneGate |
IAM-plattform med fullt OIDC-stöd. Vanlig inom offentlig sektor. |
| Keycloak |
Open source IAM-lösning med komplett OIDC-implementation. |
| ADFS |
Active Directory Federation Services. Stödjer OIDC från version 2016. |
| PhenixID |
Svensk IAM-lösning med OIDC-stöd. Används av flera kommuner. |
Rekommendation: Kontakta er IT-avdelning eller IAM-ansvarig för att identifiera vilken plattform som redan finns på plats och kan konfigureras för anslutning till Kommuna. I de flesta fall krävs endast en klientregistrering i befintlig infrastruktur.
4. Tekniska krav på OpenID Provider
4.1 Protokollkrav
Kommunens OpenID Provider (OP) ska uppfylla följande krav:
- Stödja OpenID Connect Core 1.0-specifikationen.
- Implementera Authorization Code Flow med PKCE (Proof Key for Code Exchange).
- Tillhandahålla en publik Discovery-endpoint (/.well-known/openid-configuration).
- Stödja HTTPS med giltigt TLS-certifikat (minst TLS 1.2).
- Signera ID-tokens med RS256 eller ES256.
4.2 Obligatoriska endpoints
Följande endpoints ska exponeras av kommunens OpenID Provider:
| Endpoint |
Beskrivning |
| Authorization Endpoint |
Initierar autentiseringsflödet och returnerar authorization code. |
| Token Endpoint |
Utbyter authorization code mot access token och ID token. |
| UserInfo Endpoint |
Returnerar claims om den autentiserade användaren. |
| JWKS Endpoint |
Tillhandahåller publika nycklar för verifiering av signerade tokens. |
| End Session Endpoint |
Hanterar utloggning och sessionsterminering (rekommenderas). |
4.3 Obligatoriska claims
ID-token ska innehålla följande claims för korrekt identifiering av användaren:
| Claim |
Typ |
Beskrivning |
| sub |
Obligatorisk |
Unikt och beständigt användar-ID. |
| email |
Obligatorisk |
Användarens e-postadress. |
| name |
Rekommenderad |
Fullständigt namn för visning i gränssnittet. |
| given_name |
Valfri |
Förnamn. |
| family_name |
Valfri |
Efternamn. |
| groups |
Valfri |
Gruppmedlemskap för behörighetsstyrning. |
4.4 Obligatoriska scopes
Tjänsterna inom Kommuna kommer att begära följande scopes vid autentisering:
- openid – Obligatoriskt för OIDC-flödet.
- profile – För att erhålla namn och profilinformation.
- email – För att erhålla e-postadress.
5. Klientregistrering
Följande uppgifter behöver utbytas vid registrering:
5.1 Från kommunen till Kommuna
- URL till Discovery-endpoint (/.well-known/openid-configuration).
- Alternativt: Issuer URL om Discovery stöds.
- Eventuella specifika konfigurationskrav.
5.2 Från Kommuna till kommunen
- Client ID – Unik identifierare för tjänsten som klient.
- Client Secret – Hemlighet för autentisering av klienten (om applicable).
- Redirect URI – URL dit användaren omdirigeras efter autentisering.
- Post-logout Redirect URI – URL för omdirigering efter utloggning.
6. Autentiseringsflöde
Tjänsterna inom Kommuna använder Authorization Code Flow med PKCE enligt följande steg:
- Användaren initierar inloggning i tjänsten.
- Tjänsten (Relying Party) omdirigerar till kommunens OpenID Provider.
- Användaren autentiserar sig enligt kommunens policy.
- OpenID Provider returnerar en authorization code till tjänsten.
- Tjänsten utbyter authorization code mot tokens via Token Endpoint.
- Tjänsten validerar ID-token och extraherar användarinformation.
- Användaren får tillgång till tjänsten.
7. Säkerhetskrav
- Alla kommunikationskanaler ska använda HTTPS med TLS 1.2 eller högre.
- ID-tokens ska signeras med asymmetrisk kryptering (RS256 eller ES256).
- Access tokens bör ha en begränsad livslängd (rekommenderat: 1 timme).
- Refresh tokens ska stödjas för att upprätthålla sessioner utan ny inloggning.
- PKCE ska användas för att skydda mot authorization code interception.
- State-parameter ska valideras för att förhindra CSRF-attacker.
Säkerhet
Säkerhet är en grundpelare i Kommunas arkitektur. Här beskrivs de
säkerhetsåtgärder som tillämpas.
Dataskydd
- All data krypteras i transit (TLS 1.3) och i vila (AES-256)
- Personuppgifter hanteras enligt GDPR
- Data lagras inom EU (Sverige när möjligt)
- Regelbundna säkerhetskopior med geografisk redundans
Åtkomstkontroll
- Rollbaserad åtkomstkontroll (RBAC)
- Multifaktorautentisering (MFA) för administrativa funktioner
- Principen om minsta behörighet tillämpas
- Automatisk utloggning efter inaktivitet
Övervakning och loggning
- Centraliserad logghantering med 12 månaders retention
- Realtidsövervakning av säkerhetshändelser
- Automatiska varningar vid avvikande beteende
- Regelbundna säkerhetsgranskningar och penetrationstester
Incidenthantering
Kommuna har etablerade rutiner för incidenthantering med definierade
SLA:er för responstid och eskalering. Vid säkerhetsincidenter
kontaktas berörda kommuner omedelbart.
API-dokumentation
Kommunas tjänster exponeras via moderna RESTful API:er. Här beskrivs
grunderna för att integrera mot plattformen.
Autentisering
Alla API-anrop kräver autentisering via OAuth 2.0 eller API-nycklar.
Authorization: Bearer <access_token>
Bas-URL
https://api.kommuna.se/v1/
Vanliga endpoints
GET
/services
Lista alla tillgängliga tjänster
GET
/services/{id}
Hämta information om en specifik tjänst
POST
/ai/analyze
Skicka data för AI-analys
GET
/integrations/status
Kontrollera status för integrationer
Felhantering
API:et returnerar standardiserade felmeddelanden i JSON-format:
{
"error": {
"code": "UNAUTHORIZED",
"message": "Ogiltig eller utgången token",
"details": "Förnya din access token och försök igen"
}
}
Rate limiting
API-anrop begränsas till 1000 förfrågningar per minut per kommun.
Headers indikerar kvarvarande kvot:
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 985
X-RateLimit-Reset: 1640000000