You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

Övergripande beskrivning

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 är framtagen inom Samordnad identitet och böhörighet och Sweden Connect.

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 som:
• Trust Anchor
• Intermediate Entity
• Resolver

Arkitektur och driftläge

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

  1. Standalone mode
    Instanskonfiguration hanteras lokalt via properties/YAML-konfiguration.
  2. Managed mode
    Instanser hämtar sin konfiguration från ett externt registry-system. Detta möjliggör central administration och webbgränssnitt för federationshantering. I detta läge kan flera noder grupperas bakom lastbalanserare och dela gemensam federation-konfiguration.
    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

  • 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ågaSvarKommentar
  1. 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.
  • 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.
  1. Vad avses med plattformsstöd?
    SVAR: Ändrat till krav på operativsystem, hådrvaruplattformar och databaser
  2. Vad avser ni med behov av licenser?
    SVAR: Stryker denna fråga; det viktiga är att veta kraven på databaser som sådant.
  3. Vad avses med Open source utan support?
    SVAR: Omformulerat frågan.

4. Åtkomstkontroll:

    • Styrs vi 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

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: 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.

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)

TODO!

Frågeställningarna behöver förtydligas

  1. Vilken komponent är det som avses?
    SVAR: Torde vara den separata komponent som nämnts som kan agera adapter mellan Auktorisationsserver (KeyCloak) och Uppslagstjänsten.

  2. Vilket notifieringsprotokoll avses? 
    1. Mellan vilka komponenter?
      SVAR: Samma komponenter som ovan. Justerar frågan då notifieringsprotokoll är om ens tillämpligt en del av svaret/lösningen.
  • No labels