Allmän teknisk information

Den tekniska infrastrukturen för Skolfederation har byggts upp med samma standarder som redan används för den svenska universitets- och högskolefederationen SWAMID.

Standardprofil för Skolfederation

Skolfederation har likt andra federativa initiativ som ambition att använda följande SAMLv2-profiler:

Aktörskrav

Tjänsteleverantör (SP, service providers)

Skolfederations tjänsteleverantörer ska ha förmågan att konsumera intyg.

Användarorganisation (IdP, identity providers)

Skolfederations användarorganisationer ska ha förmågan att identifiera och autentisera användare, exempelvis elever, och som ett resultat av detta ställa ut ett intyg.

Federationsoperatör

Federationsoperatören ska tillhandahålla digitalt signerat aggregerat SAML-metadata vilket kan anses vara Skolfederationens kärna, den grundläggande tilliten.

Övergripande teknisk infrastruktur

SAML-metadata (MD)

För att aktörerna i Skolfederation ska kunna lita på varandras intyg krävs ett utbyte av de publika nycklarna i varje aktörs nyckelpar och därigenom kan intygets signatur verifieras. Utbytet sker genom att lokalt SAML-metadata, vilket beskriver en aktörens egenskaper, förmågor och publika nycklar, aggregeras till federationsoperatören vilken digitalt signerar och publicerar det aggregerade SAML-metadatat, vilket således innehåller federationens samtliga aktörers egenskaper, förmågor och publika nycklar.

I saml2int beskrivs hur SAML-metadata skall presenteras. Utformningen av SAML-metadata regleras i OASIS SAML V2.0 metadata specification [SAML2Meta] och hantering av SAML-metadata regleras i OASIS Metadata Interoperability Profile [MetaIOP]. Samtliga ingående aktörer i Skolfederation skall stödja dessa.

Validering och uppladdning av metadata

Innan du skickar in metadata till federationen bör du själv validera den mot Skolfederation. Se information under fliken Metadata. I enlighet med nya dataskyddsförordingen, GDPR rekommenderar Skolfederation att kontaktinformationen i ert metadata är i form av så kallade funktionsbrevlådor.

Publicering av metadata

Skolfederations aggregerade och signerade metadata publiceras här:

Federationsoperatörens publika nyckel för verifiering av metadata återfinns här:

Varje ingående aktör ska signaturverifiera SAML-metadata vid varje förändring mot minst en nyckelkälla.

Autentiseringsförfrågan

I grundscenariot där en användare, exempelvis elev, önskar använda en tjänst, men är oidentifierad blir denne ombedd att autentisera sig. Den förfrågan som tjänsten skapar i detta scenario är en autentiseringsförfrågan vilken användaren tar med sig till intygsutfärdaren (IdP).

Skolfederationen har valt att använda saml2int som deploymentprofil vilken tydligt beskriver hur SAML V2.0 Web Browser SSO Profile [SAML2Prof] ska användas, vilket i sin tur återspeglar sig på autentiseringsförfrågan.

Autentiseringssvar

Autentiseringssvaret kan vara en följd av en autentiseringsförfrågan, men det kan också vara ett autentiseringssvar utan någon föregående autentiseringsförfråga.

Skolfederationen har valt att använda saml2int som deploymentprofil vilken tydligt beskriver hur SAML V2.0 Web Browser SSO Profile [SAML2Prof] ska användas vilket i sin tur återspeglar sig på autentiseringssvaret. Där återfinns bland annat:

  • att kommunikationen ska skyddas med TLS/SSL
  • att autentiseringssvaret ska signeras
  • att tjänster ska acceptera o-ombedda intyg (unsolicited respons).

Pseudonymer

Skolfederation värnar om den personliga integriteten. Därför är det av vikt att samtliga ingående parter kan hantera pseudonymer som identifieringsbegrepp (subjekt). Följande två format som är en del av SAML2Core5 ska stödjas:

  • urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
  • urn:oasis:names:tc:SAML:2.0:nameid-format:transient

Persistenta pseudonymer har egenskapen att de alltid mappar en användare till samma pseudonym per tjänst. Det vill säga att olika tjänster ger olika pseudonymer.

Transienta pseudonymer mappar aldrig en användare till samma pseudonym, utan användaren får en ny pseudonym vid varje nytt tillfälle och för varje tjänst.

Anvisningstjänst (DS)

I grundscenariot där en användare, exempelvis elev, önskar använda en tjänst, men är oidentifierad så blir denne ombedd att autentisera sig. I en tvåpartsrelation vet tjänsten vilken intygsutfärdare (IdP) som denne ska anvisa användaren till. I en federation likt Skolfederationen med 100-talet intygsutfärdare krävs sålunda en funktion för att anvisa användaren till ”sin” intygsutfärdare. Funktionen benämns anvisningstjänst (discovery services).

Det bör poängteras att en central anvisningstjänst inte är en nödvändighet utan tjänsteleverantören kan själv välja att implementera en funktion för lokal anvisning baserat på SAML-metadata.

Det bör också poängteras att det finns möjlighet till ett scenario med o-ombedda intyg (unsolicited respons). Där ansluter användaren först till sin intygsutfärdare (IdP) med en parameter i anropet som sedan används för att anvisa användaren till rätt tjänst (SP).

Hantering av anvisning regleras av OASIS Identity Provider Discovery Service Protocol Profile [IdPDisco]. Samtliga ingående aktörer i Skolfederationen skall stödja detta.

Single logout

Skolfederation har inledningsvis inget krav på att ingående aktörer ska stödja single-logout. Skolfederation sätter dock inte några infrastrukturella hinder att implementera single-logout.

Attributstjänst (AA)

Skolfederations intressenter har inte inledningsvis pekat på några för federationen gemensamma attributstjänster (AA, Attribute Authority). Skolfederation sätter dock inte några infrastrukturella
hinder att implementera attributstjänster.