Page History

Övergripande beskrivning

draw.io Diagram

border	false

diagramName	oidf-services
simpleViewer	false
width
links	auto
tbstyle	inline
lbox	true
diagramWidth	1481
height	518
revision	1

openid-federation-services är en Java/Spring Boot-baserad komponent för att exponera och hantera tjänster enligt OpenID Federation 1.0. Komponenten implementerar centrala federationstjänster för att möjliggöra dynamisk tillitshantering inom en OpenID Federation-baserad infrastruktur. (github.com)

...

Komponenten stödjer funktioner för:•

Publicering av federationsmetadata

...

Hantering av trust chains och trust anchors

...

Federation discovery och metadata-upplösning

...

Hantering av subordinate statements

...

Utfärdande och hantering av trust marks

...

Validering och distribution av federationstillit mellan anslutna parter

Komponenten kan agera somagera som:•

Trust Anchor
Resolver

...

Intermediate Entity

...

Trustmark Issuer

Arkitektur och driftläge

Tjänsten kan köras i två huvudsakliga driftlägen:

Lokal konfigurationStandalone mode
Instanskonfiguration hanteras lokalt via properties/YAML-konfiguration.
Managed modeRegistry-baserad konfiguration
Instanser hämtar sin konfiguration från ett externt registry-systemOpenID Federation Registry. Detta möjliggör central administration och via ett webbgränssnitt för federationshantering. I detta läge kan flera noder grupperas bakom lastbalanserare och dela gemensam federation-konfiguration. Flera instanser kan dela samma konfiguration och köras bakom en lastbalanserare för hög tillgänglighet.
OBS! OpenID Federation Registry utvecklas fortfarande och är inte släppt som open source

Arkitekturen är avsedd för horisontell skalning där flera federation-noder kan exponera samma tjänster bakom lastbalanserare.

Konfiguration

Konfiguration sker primärt via Spring Boot-konfiguration (application.yaml eller miljövariabler).

Exempel på typiska konfigurationsparametrar:

• Entity ID för trust anchor/intermediate
• Signeringsnycklar och certifikat
• Endpoint-URL:er
• Registry-anslutning i managed mode
• Federation policies
• Trust mark-konfiguration

Projektet använder även gemensamma bibliotek från openid-federation-commons, vilket innehåller grundfunktioner för federation, trust chain-validering och klientstöd. (github.com)

Drift

...

Lokal konfiguration

OpenID Federation Services kan konfigureras lokalt med hjälp av applikationens konfigurationsfiler. Konfigurationen styr vilka federationsentiteter instansen representerar, vilka federationstjänster som exponeras och vilket metadata som publiceras.

Konfigurationens struktur

Den lokala konfigurationen är uppbyggd kring de federationsentiteter som instansen representerar.

På övergripande nivå består konfigurationen av:

gemensamma inställningar
Trust Anchors
Intermediates
Resolvers
Trust Mark Issuers

Exempel på struktur:

federation
└── local-registry
    ├── trust-anchors
    ├── intermediates
    ├── resolvers
    └── trust-mark-issuers

Varje federationsentitet konfigureras separat.

För respektive federationsentitet kan bland annat följande information konfigureras:

Entity Identifier
Signeringsnycklar (JWKS)
Endpoints
Metadata
Metadata Policies
Constraints
Trust Marks
Underordnade entiteter
Administration av underordnade entiteter

En Trust Anchor eller Intermediate administrerar vilka underordnade entiteter som ingår i federationen. De underordnade entiteterna används för att generera Federation List Endpoint och för att utfärda Subordinate Statements.

Vid lokal konfiguration definieras de underordnade entiteterna under federation.local-registry.

Varje Trust Anchor eller Intermediate innehåller en lista med subordinates, där respektive underordnad entitet konfigureras.

För varje underordnad entitet kan bland annat följande information anges:

Entity Identifier
Entity Configuration eller ec_location
JWKS
Metadata Policy
Constraints
Kritiska metadatafält (crit)

Konfigurationen avgör vilka entiteter som exponeras via Federation List Endpoint och vilket innehåll som används när Entity Statements genereras.

Exempel

Följande exempel visar den övergripande strukturen för en lokal konfiguration.

federation:
  local-registry:
    trust-anchors:
      - entity-id: https://ta.example.se
        subordinates:
          - entity-id: https://rp.example.se
          - entity-id: https://as.example.se

Drift

Komponenten levereras som öppen källkod i form av en Spring Boot-applikation.
För att underlätta installation och drift publiceras även container-images.
Driftmiljö, driftsättning och förvaltning väljs och ansvaras för av den organisation som använder komponenten

Status

Versionsinformation: openid-federation-services/docs/release-notes.md at main · swedenconnect/openid-federation-services

Fråga Svar Kommentar

Krav på driftsmiljöer:

- Ställs krav på HSM för signeringsnyckel samt genomförande av nyckelscermoni?
- Specifikat krav på driftsmiljö för Pilot, Exvis om det räcker med TEST-miljö under piloten

Piloten avses att köras i produktion

Eventuellt HSM krav kommer att beskrivas i 'Krav på anslutningsoperöter' enligt federationsplattformen

2. Konnektivitetskrav: vilka tjänster/ändpunkter som behöver vara nåbara och mellan vilka komponenter, till exempel

- Anslutningstjänster till Tillitsankaret
- Protokollentiteter till Anslutningstjänst och Uppslagstjänst

Samtliga federationsentiteter ska vara nåbara för hämtning av Entity Configuration, medan anslutningstjänster, tillitsankare och eventuella uppslags- och verifieringstjänster ska vara nåbara via de endpoints som krävs för metadatavalidering.

Protokollentitet
- /.well-known/openid-federation.
Anslutningstjänst (Intermediate)
- /.well-known/openid-federation
- federation_fetch_endpoint
- federation_list_endpoint.
Tillitsankare
- /.well-known/openid-federation
- federation_fetch_endpoint
- federation_list_endpoint.
Resolver
- federation_resolve_endpoint

Kommentar: Enligt OpenID Federation 1.0 är endast /.well-known/openid-federation en standardiserad URL-sökväg. Övriga endpoints, definieras av respektive entitet och publiceras i dess Entity Configuration.

3. Systemkrav:

- Operativsystem
- Hårdvaruarkitektur
- Databaser
- Krav på supportavtal för underliggande databaser för piloten?

Leveransen består av öppen källkod och inte en färdig produkt med definierade krav på plattform, specifika databaser eller supportavtal.

Operativsystem
- OpenID Federation Services är utvecklad i Java/Spring Boot och är inte beroende av ett specifikt operativsystem.
- Kan köras på plattformar som stöder aktuell Java-runtime, exempelvis Linux eller Windows Server.
- Linux rekommenderas för produktionsdrift.
Hårdvaruarkitektur
- Ingen specifik hårdvaruarkitektur krävs av lösningen.
- Kan köras på standardplattformar baserade på x86_64.
- Även ARM-baserade miljöer kan användas förutsatt att vald Java-version stöds.
- Tjänsterna är stateless och kan skalas horisontellt genom att flera instanser körs bakom en lastbalanserare

.

- (kräver Redis)
Databaser
- Open source-komponenten har inget krav på en specifik databasprodukt.
- Lösningen kan köras utan att databasteknik exponeras som en del av leveransen.
- Eventuella databasval är kopplade till den miljö där komponenterna driftsätts och förvaltas, inte till själva open source-komponenten.
Krav på supportavtal för underliggande databaser för piloten
- Inga krav på kommersiella supportavtal för databaser ställs av den levererade open source-komponenten.
- Eventuella krav på support eller supportavtal för databaser avgörs av den organisation som ansvarar för driftmiljön.

Vad avses med plattformsstöd?
SVAR: Ändrat till krav på operativsystem, hådrvaruplattformar och databaser
Vad avser ni med behov av licenser?
SVAR: Stryker denna fråga; det viktiga är att veta kraven på databaser som sådant.
Vad avses med Open source utan support?
SVAR: Omformulerat frågan.
Är lösningen byggd så att den är transparent för val av databas?

4. Åtkomstkontroll:

- Styrs

vi

via konfigurationsfiler Konfigurationer för inloggning i federationstjänster	OpenID Federation Services omfattar inte åtkomstkontroll Standalone mode, instanskonfiguration hanteras lokalt via properties/YAML-konfiguration.
5. Ip-adresser och routing: Hur många externa ip-adresser kommer Anslutningstjänst+Resolver att behöva? Ska adresserna kunna routas över både Internet och Sjunet?	Routing över Internet Antalet externa IP-adresser beror på hur lösningen väljer att exponeras och vilka krav som finns på nätverksseparering mellan olika tjänster och miljöer. Anslutningstjänst och Resolver kan exponeras via samma externa IP-adress och DNS-namn, men det är också möjligt att använda separata IP-adresser och DNS-namn för respektive tjänst eller miljö. Det finns inget generellt krav på ett visst antal externa IP-adresser.	För Sweden Connect kommer samtliga tjänster att exponeras via ett gemensamt DNS-namn och en gemensam extern IP-adress.
6. Externa certifikat för TLS på publika endpoints Något särskilt att tänka på för piloten? Hur ska resolverns certifikat skapas Hur är relationen till Digg Signeringscertifikat?	Publika TLS certifikat ska användas för endpoints
7. Autentisering och behörighet för Admin Nyttja KeyCloak från start, eller konfigurera användare direkt i Admin-delen till en början?	Standalone mode:

instanskonfiguraion

instanskonfiguration hanteras lokalt via properties/YAML-konfiguration.

OpenID Federation Registry kommer på sikt kunna användas för konfigurera OpenID Federation Services i managed mode.

Status

colour	Yellow
title	Todo!

Frågan avser hur realiseras behörigheterna för att kunna administrera federationstjänsterna, dvs. Admin-applikationen.

8. Beskrivning av komponent som integrerar mellan auktorsationsserver federationstjänsten Resolver (Uppslagstjänst).

Status

colour	Yellow
title	Todo!

Frågeställningarna behöver förtydligas

Vilken komponent är det som avses?
SVAR från Per: Torde vara den separata komponent som nämnts som kan agera adapter mellan Auktorisationsserver (KeyCloak) och Uppslagstjänsten.
Vilket notifieringsprotokoll avses?
1. Mellan vilka komponenter?
  SVAR från Per: Samma komponenter som ovan. Justerar frågan då notifieringsprotokoll är om ens tillämpligt en del av svaret/lösningen.

9. Avser Digg tillhandahålla Open Source-komponenteter enligt följande alternativ:

Docker-images vilka löpande uppdateras
Som källkod

Gäller både under piloten samt på sikt

Status

colour	Yellow
title	Todo!

10. När planeras adminportalen levereras, omfattning över tid?

Status

colour	Yellow
title	Todo!

Page tree

Versions Compared

Old Version 10

New Version Current

Key

Övergripande beskrivning

Arkitektur och driftläge

Lokal konfiguration

Konfigurationens struktur

Drift

Status