SAML-Profil
Samverkan för Behörighet och Identitet inom hälsa, vård och omsorg.
Revisionshistorik
Version | Datum | Författare | Kommentar |
---|---|---|---|
0.8 |
| Upprättad | |
1.0rc1 |
| Reviderad | |
1.0 |
| Former user (Deleted) | Fastställd |
1.1 |
| Rättning kring logout-bindings. SKALL → KAN vad gäller IDP-stöd för SOAP binding för utfärdande av LogoutResponse | |
1.2 |
| Krav på signering av artifact resolve meddelanden | |
2.1 |
| Lagt till endpoints för Underskrifts metadata | |
2.2 | Pär Hylback | Lagt till exempel dubbla cerificat |
Introduktion
Denna profil definierar ett urval av alla tekniker och lösningar som definieras av SAML samt SAMBI Attributspecifikation 1.4.. Syftet är att implementatörer kan anpassa sig enligt krav i denna profil och på så sätt säkert erhålla interoperabilitet dem emellan.
Profilen är framtagen för att SAML Web SSO skall fungera i federerad miljö med olika produkter, så att sann Web SSO kan erhållas.
Profilen är en utökning på OASIS specifikationer gällande SAML V2.0 (se referenser). För att uppfylla denna profil SKALL alla krav i denna profil samt kraven som OASIS ställer i sina specifikationer (primärt SAML Web SSO profile) vara uppfyllda. Denna profil försöker inte upprepa sådana krav som finns i grundspecifikationerna.
Två existerande profiler har valts som arbetsunderlag för framtagandet av denna profil. Dessa är
- Kantara Initiative eGovernment Implementation Profile of SAML V2.0 [eGov2]
- Interoperable SAML 2.0 Web Browser SSO Deployment Profile [SAML2Int]
- SAMBI Tekniska krav (https://www.sambi.se/medlem-i-sambi/avtal-och-bilagor/#tekniska-krav)
Notation
Tjänsteleverantör (Service Provider) benämns som SP genomgående i profilen.
Identifikationsleverantör (Identity Provider) benämns som IdP genomgående i profilen.
Senast vald IdP (om sådan finns) benämns som SSO IdP genomgående i profilen.
XML Element skrivs med "oformaterat" typsnitt
<saml2p:AuthnRequest>
Hänvisning till referenser skrivs inom hakparenteser [referensidentifikation]
- SKALL är de krav som måste uppfyllas för att vara kompatibel med denna profil.
- KAN är de krav som är frivilliga, huruvida de uppfylls eller inte påverkar inte kompatibiliteten mot denna profil.
- BÖR är krav som rekommenderas att följas.
XML namnrymd
Följande namnrymder hanteras av profilen
Prefix | Namnrymd |
---|---|
saml2 | urn:oasis:names:tc:SAML:2.0:assertion |
saml2p | urn:oasis:names:tc:SAML:2.0:protocol |
md | urn:oasis:names:tc:SAML:2.0:metadata |
idpdisco | urn:oasis:names:tc:SAML:profiles:SSO:idp-disovery-protocol |
mdattr | urn:oasis:names:tc:SAML:metadata:attribute |
ds | http://www.w3.org/2000/09/xmldsig# |
Metadata och förlitande hantering
SAML Metadata SKALL användas för att distribuera information mellan SAML-entiteter.
IdP och SP SKALL stödja SAML V2.0 Metadata Interoperability Profile Version 2.0 [MetaIOP]
IdP och SP SKALL stödja import och export av SAML V2.0 Metadata dokument.
IdP och SP BÖR stödja import och export av dokument genom följande metoder
- Filresurs
- Publicera och erhålla via “Well-Known Location”, definierad av [SAML2Meta]
Implementationer SKALL stödja PKIX och BÖR stödja OCSP/CRL för att säkerställa status på SAML entiteters certifikat, som används till ex. signering, server autentiserad SSL/TLS etc.
Implementationer KAN stödja ytterligare metoder för att säkerställa certifikat, ex. kontrollera certifikatets subjektnamn.
IdP och SP SKALL stödja metadatadokument vars rot-element är <md:EntityDescriptor>
eller <md:EntitiesDescriptor>
.
<KeyDescriptor> <X509Data> <X509Certificate>Certifikat 1 ..... </X509Certificate> </X509Data> </KeyDescriptor> <KeyDescriptor> <X509Data> <X509Certificate> Certifikat 2 ..... </X509Certificate> </X509Data> </KeyDescriptor>
SP SKALL använda funktionscertifikat som är godkänd för anslutning till IdP, se Guide till IdP.
IdP Metadata
IdP SKALL hantera metadata enligt följande
- SKALL finnas ett
<md:IDPSSODescriptor>
element. - SKALL finnas minst en
<md:KeyDescriptor>
som innehåller ett<ds:KeyInfo>
som i sin tur identifierar IdPs certifikat via<ds:X509Certificate>
. - SKALL finnas ett eller flera
<md:NameIDFormat>
som identifierar vilka namn-id format som stödjas. - SKALL finnas
<md:SingleSignOnService>
i enlighet med definierade bindings. - SKALL finnas en
<md:Organization>
som identifierar ansvarig organisation. - SKALL finnas minst en
<md:ContactPerson contactType="support">
samt minst en<md:ContactPerson contactType="technical">
.
SP Metadata
- Om [IdPDisco] används BÖR ett eller flera
<idpdisco:DiscoveryResponse>
finnas (under<md:Extensions>
element), som beskriver vart IdP discovery svaret skall skickas. Om IdPDisco används och SP saknar<idpdisco:DiscoveryResponse>
måste HTTP parameter för svaret anges enligt [IdPDisco]. - SKALL finnas ett
<md:SPSSODescriptor>
element. - SKALL finnas minst en
<md:keyDescriptor>
som innehåller ett<ds:KeyInfo>
som i sin tur identifierar SPs certifikat via<ds:X509Certificate>
.- För krav på SPs funktionscertifikat, se Guide till Inera IdP.
- SKALL finnas ett eller flera
<md:NameIdFormat>
som identifierar vilka namn-id format som stödjs. - SKALL finnas
<md:AssertionConsumerService>
i enlighet med definierade bindings. - Om
<saml2:AttributeStatement>
förväntas i<
saml2p:Response>
SKALL<md:AttributeConsumingService>
finnas, den ska beskriver vilka tjänster SP tillhandhåller, samt dess egenskapsbehov. - SKALL finnas
<md:SingleLogoutService>
som beskriver vilka SLO-tjänster SP tillhandahåller (om SP:n stödjer SLO). - SKALL finnas ett
<md:Organization>
element som namnger organsiationen för denna SP. - SKALL finnas ett
<md:ContactPerson>
element med egenskap "contactType
" satt till "support" samt ett med "contactType
" satt till "technical".
Namn-id format
IdP SKALL stödja samtliga nedanstående namn-id format, och SP SKALL stödja minst ett.
Format | Beskrivning |
---|---|
| Permanent id som återanvänds mellan sessioner. Id är unikt för kombinationen Subjekt och SP. Id är genererat och ingen personinformation kan utläsas. |
urn:oasis:names:tc:SAML:2.0:nameid-format:transient | Aktören får ett nytt id vid varje ny SSO-session. Ett id för varje SP. Id är genererat och ingen personinformation kan utläsas. |
Egenskaper
<saml2:Attribute>
SKALL innehålla egenskapen NameFormat
som är satt till urn:oasis:names:tc:SAML:2.0:attrname-format:uri
.
SKALL innehålla 1..* <saml2:AttributeValue>
som då är text (kan vara vanlig text eller formatterade text exempelvis JSON).
SAML attribut
Egenskaper när uppgifter i attributkälla saknas
Följande egenskaper kan erhållas även om aktören saknas i attributkällan.
- http://www.w3.org/2000/09/xmldsig#X509IssuerName (endast vid autentisering genom certifikat)
- http://www.w3.org/2000/09/xmldsig#X509SubjectName (endast vid autentisering genom certifikat)
- urn:sambi:names:attribute:authnMethod
- urn:sambi:names:attribute:levelOfAssurance
SSO IdP Identifiering
Detta kapitel identifierar metoder och tekniker som används för att identifiera SSO IdP.
Vid autentisering SKALL identifiering av aktör alltid göras mot den s.k. SSO IdP, detta för att erhålla sann Web SSO.
- I enlighet med SAMBI använder SP Identity Discovery Protocol and Profile [IdPDisco] för att erhålla aktörens SSO IdP.
Autentisering
Begäran
Bindningar och säkerhetskrav
- SP SKALL stödja HTTP-Redirect bindning för utfärdande av begäran.
- IdP SKALL stödja HTTP-Redirect bindning för mottagande av begäran.
- SSL/TLS SKALL användas för att säkra kommunikationen.
Begärans innehåll
SP KAN stödja, att delge vid behov, följande element
<saml2:AssertionConsumerServiceURL>
och<saml2:ProtocolBinding>
eller<saml2:AssertionConsumerServiceIndex>
<saml2:ForceAuthn>
<saml2:IsPassive>
<saml2:AttributeConsumingServiceIndex>
<saml2p:RequestedAuthnContext>
<saml2p:NameIDPolicy>
<saml2:Subject>
IdP SKALL stödja alla ovan nämnda element som definieras av [SAML2Core].
IdP SKALL verifiera att begärande SP och angiven <saml2p:AssertionConsumerService...>
är överensstämmande (med hjälp av SAML Metadata).
<saml2p:AuthnRequest>
KAN innehålla ett <saml2:Subject>
, huruvida IdP använder det eller inte är upp till IdP.
Om <saml2p:RequestedAuthnContext>
anges SKALL egenskapen "comparison
" utelämnas eller vara satt till "exact
".
Svar
Bindningar och säkerhetskrav
- SP SKALL stödja HTTP-Post, alternativt HTTP-Artifact för mottagande av svaret.
- IdP SKALL stödja HTTP-Post för utfärdande av svaret.
- SP KAN stödja HTTP-Artifact för mottagande av svaret (se HTTP-Artifact kaptiel nedan).
- IdP SKALL stödja HTTP-Artifact för utfärdande av svaret (se HTTP-Artifact kapitel nedan).
<saml2:EncryptedId>
och<saml2:EncryptedAttribute>
BÖR inte användas.- IdP SKALL signera
<saml2:Assertion>
elementet (alltså inte<saml2:Response>
elementet). - SP och IdP SKALL hantera ”unsolicitated responses”
- SSL/TLS SKALL användas för att säkra kommunikationen.
HTTP-Artifact
- Om HTTP-Artifact används måste följande följas.
- SKALL stödja ”Artifact resolution” enligt [SAML2Prof].
- SOAP SKALL användas för
<saml2p:ArtifactResolve>
och<saml2p:ArtifactResponse>
. - IDP och SP SKALL signera
<saml2p:ArtifactResolve>.
- Artifakt format
urn:oasis:names:tc:SAML:2.0:artifact-04
SKALL stödjas, definierat i [SAML2Prof].
Svarets innehåll
<saml2:Response>
SKALL innehålla maximalt en<saml2:Assertion
, en<saml2:AuthnStatement>
och en<saml2:AttributeStatement>
.<saml2:Subject>
KAN innehålla ett<saml2:NameID>
.- SP SKALL verifiera att signaturen på
<saml2:Assertion>
elementet är korrekt (med hjälp av SAML Metadata).
Underskrift
Tjänster ansluter inte direkt mot IdP:n för underskrift utan denna integration görs mellan underskrifttjänsten och IdP:n.
Metadata för det kan hittas under
- <IDPURL>/saml/sign
- <IDPURL>/saml/sign/sithseid-other-device
- <IDPURL>/saml/sign/sithseid-same-device
Metadatan är för respektive inloggningsmetod.
Denna ska inte användas av SP.
Utloggning (SLO)
IdP propagerar inte utloggningsbegäran till andra SP. Vid korrekt utloggningsbegäran från SP avslutas den aktuella IdP-sessionen vilket förhindrar fortsatt SSO och SP erhåller ett LogoutResponse.
Initierande begäran SKALL skickas över front-channel binding (HTTP-Redirect alt HTTP-POST). Svar sker på respektive SP föredragen bindning (med hjälp av metadata).
Begäran
Bindning och säkerhetskrav
- IdP SKALL stödja HTTP-POST och HTTP-Redirect för mottagande av
<saml2p:LogoutRequest>
. - IdP KAN stödja SOAP för mottagande av
<saml2p:LogoutRequest>
. - SP SKALL stödja HTTP-Redirect och HTTP-POST för utfärdande av
<saml2p:LogutRequest>
. - SP KAN stödja SOAP och HTTP-POST för utfärdande av
<saml2p:LogoutRequest>
. - SP SKALL signera
<saml2p:LogoutRequest>
vid front-channel. - SSL/TLS SKALL användas för att säkra kommunikationen.
Webb-läsare (User Agent)
- IdP SKALL stödja aktörs-initierad utloggning.
- SP SKALL tillåta aktörs-initierad utloggning.
Svar
Bindning och säkerhetskrav
- IdP SKALL stödja HTTP-Redirect samt HTTP-POST för utfärdande av
<saml2p:LogoutResponse>
. - IdP KAN stödja SOAP för utfärdande av
<saml2p:LogoutResponse>
. - SP SKALL stödja HTTP-Redirect och/eller SOAP och/eller HTTP-POST för mottagande av
<saml2p:LogoutResponse>
. - SSL/TLS SKALL användas för att säkra kommunikationen.
Authentication Context (AuthnContext)
Detta kapitel definierar AuthnContext tillitsnivå (assurance level), enligt [IAFAL]. Tillitsnivån medföljer utställt SAML-intyg (se kapitel Egenskaper).
Tillitsnivåer (LoA)
Följande tillitsnivåer definieras av denna profil:
Tillitsnivå LoA1
Låg tillit till en aktörs identitet.
Identifikation: http://id.sambi.se/loa/loa1
Tillitsnivå LoA2
Viss tillit till en aktörs identitet.
Identifikation: http://id.sambi.se/loa/loa2
Tillitsnivå LoA3
Hög tillit till en aktörs identitet.
Identifikation: http://id.sambi.se/loa/loa3
Tillitsnivå LoA4
Mycket hög tillit till en aktörs identitet.
Identifikation: http://id.sambi.se/loa/loa4
Identifikationsmetoder
Nedan definieras den identifikationsmetod som initialt stöds. Aktuell identifikationsmetod medföljer utställt SAML-intyg (se kapitel Egenskaper).
SSL/TLS Certificate-Based Client Authentication
Identifikation: urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient
Tillitsnivå: Beror på egenskaper i certifikatet. Detta hanteras i enlighet med https://www.inera.se/globalassets/projekt/e-identitet-for-offentlig-sektor/dokumentblock/pki/e-identitet-for-offentlig-sektor-pki-struktur.pdf.
Krav: SKALL stödjas av IdP. Denna används för att autentisera aktören genom dess X.509 certifikat (ex SITHS).
Utfärdare
IdP'n SKALL stödja följande utfärdare av användarcertifikat.
- SITHS Type 1 CA v1
Felhantering - SAML status
Vid ett fel så SKALL IdP skicka ett <Response>
till SP, förutsatt att SP:ns identitet och returadress kan verifieras mot metadata.
Returen skall innehålla en <Status>
med <StatusCode>
satt till något av följande värden:
Primär | Beskrivning |
---|---|
urn:oasis:names:tc:SAML:2.0:status:Requester | Fel av SP, t.ex om inkommande <AuthnRequest> inte passerar valideringen som görs av IdP'n |
urn:oasis:names:tc:SAML:2.0:status:Responder | Fel av IdP, eller t.ex. problem under autentiseringen. |
urn:oasis:names:tc:SAML:2.0:status:VersionMismatch | Felaktig version på inkommande <AuthnRequest> |
Vid behov kan IdP inkludera en sekundär <StatusCode>
för mer detaljerad felinfo.
Om det råder osäkerhet kring varifrån en begäran kommit, eller vart ett felmeddelande skall skickas, till exempel om det saknas SAML-metadata för SP, så kan IdP inte tillhandahålla något SAML <Response>
.
Sekundära statuskoder
Sekundär | Exempel |
---|---|
urn:oasis:names:tc:SAML:2.0:status:AuthnFailed | NiAS timeout, felaktigt cert, etc. |
urn:oasis:names:tc:SAML:2.0:status:InvalidAttrNameOrValue | |
urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy | <NameIDPolicy> i autentiseringsbegäran matchar inte tillåtna nameid-format. |
urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext | <RequestedAuthnContext> i autentiseringsbegäran kan inte uppfyllas eller matchar inte Metadata. |
urn:oasis:names:tc:SAML:2.0:status:NoAvailableIDP | |
urn:oasis:names:tc:SAML:2.0:status:NoPassive | |
urn:oasis:names:tc:SAML:2.0:status:NoSupportedIDP | |
urn:oasis:names:tc:SAML:2.0:status:PartialLogout | |
urn:oasis:names:tc:SAML:2.0:status:ProxyCountExceeded | |
urn:oasis:names:tc:SAML:2.0:status:RequestDenied | IdP vägrar kommunicera med SP av någon anledning, t.ex. säkerhetsrisker. |
urn:oasis:names:tc:SAML:2.0:status:RequestUnsupported | |
urn:oasis:names:tc:SAML:2.0:status:RequestVersionDeprecated | |
urn:oasis:names:tc:SAML:2.0:status:RequestVersionTooHigh | |
urn:oasis:names:tc:SAML:2.0:status:RequestVersionTooLow | |
urn:oasis:names:tc:SAML:2.0:status:ResourceNotRecognized | |
urn:oasis:names:tc:SAML:2.0:status:TooManyResponses | |
urn:oasis:names:tc:SAML:2.0:status:UnknownAttrProfile | |
urn:oasis:names:tc:SAML:2.0:status:UnknownPrincipal | |
urn:oasis:names:tc:SAML:2.0:status:UnsupportedBinding |
Användningsstöd
Autentisering
En förutsättning för att en SP skall kunna använda en IdP är att dessa metadata finns registrerat i IdP'n. På samma sätt är det en förutsättning att IdP'ns metadata är registrerat hos SP'n.
SP-initierad
Med detta avses inloggning som initieras hos SP'n, dvs där det är SP'n som sätter samman ett <AuthnRequest>
som den senare förmedlar till IdP'n via lämplig binding (exempelvis HTTP-Redirect).
Ur ett aktörsperspektiv så kan man se det som att aktören först försöker komma åt (anger webbadress i browsern) applikationen. SP ansvarar då för att lista ut vilken IdP som skall användas och detta leder sedan till en inloggning via just den IdP'n. Bilden nedan visar ett exempel på detta.
IdP-initierad (Unsolicited SSO)
IdP-initierad inloggning innebär att inloggningsflödet startar i IdP'n istället för hos SP'n. Man kan se det som att det är aktören som väljer IdP'n.
Detta flöde kan vara användbart i de fall en SP kan tillåta autentisering från olika IdP'er, och man vill kunna tillhandahålla en portal där användaren väljer med hjälp av vilken IdP de vill logga in i applikationen. Bilden nedan visar ett exempel på detta.
För att använda IdP-initierad inloggning görs ett GET anrop från aktörens browser in till IdP'n. Formatet på detta är enligt följande.
URL: https://<idphostname>/saml/unsolicited/sso
(där <idphostname>
byts ut mot adressen för IdP'n). Följande parametrar SKALL / KAN användas.
Parameter | Obligatorisk | Beskrivning |
---|---|---|
providerId | X | Det EntityID som den SP aktören vill logga in till har. Detta SKALL vara URLEncoded. |
shire | URL till SAML 2.0 Response location hos SP'n. (AssertionConsumerServiceURL). Om den utlämnas väljer IdP'n utifrån SP'ns metadata. Denna SKALL vara URLEncoded. | |
target | Motsvarar RelyState i SAML 2.0 protokollet. | |
time | Används inte idagsläget. |
Exempel
https://idp.ineratest.org/saml/unsolicited/sso?providerId=https%3A%2F%2Ftest.example.se%3A443%2Fsp%2Fsaml
https://idp.ineratest.org/saml/unsolicited/sso?providerId=https%3A%2F%2Ftest.example.se%3A443%2Fsp%2Fsaml&shire=https%3A%2F%2Ftest.example.se%3A443%2Fsp%2Fsaml%2FHTTP-POST
https://idp.ineratest.org/saml/unsolicited/sso?providerId=https%3A%2F%2Ftest.example.se%3A443%2Fsp%2Fsaml&target=ss%3Amem%3A6aa181259dc9ba41725ce239fe77925c430e0132cd92076dc16ebbe9806866c7
Anvisningstjänst
Hanteras av SAMBI för anslutna IdP:er/SP:ar enligt tekniska kraven under sambi anslutningsavtal.
Ange vilka attribut som SP efterfrågar
I SP-metadatat SKALL det specificeras vilka attribut som IdP:n skall (bör) leverera till SP:n. Detta görs genom att ange 1..* <md:AttributeConsumerService>
.
Se Attributstyrning SAML för mer information.
Tidsstämplar i biljetten
En saml-biljett innehåller ett flertal tids-stämplar som man som SP bör känna till.
Assertion → IssueInstant
Tidpunkt då saml-biljetten skapats av IdP:n
<saml2:Assertion ID="_466ef75b0524a76c1602e239c79bebcd33a683f1be0dff661bbcbcd80fef" IssueInstant="2018-06-12T17:25:57.695Z" Version="2.0" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
SubjectConfirmationData → notOnOrAfter
SubjectConfirmation begränsar tiden ”användaren” har på sig att presentera biljetten för SP:n. (för att undvika replay-attacker), vilket i normalfallet sätts en kort stund efter att IdP:n skapade saml-intyget (1 min i detta exempel)
<saml2:SubjectConfirmationData InResponseTo="4f80dd94-86f2-4ac1-8c41-ecbbe67edd3b" NotOnOrAfter="2018-06-12T17:26:57.703Z" Recipient="https://sp.dev.inera.test:8881/api/saml/sso/HTTP-POST"/>
Conditions → notOnOrAfter
IdP:n kan sätta en tidpunkt fram till vilken biljetten är giltig. Om det sätts och hur länge kan t.ex. styras genom ett ramverk (typ sambi) i en federation. Men i princip skulle en IdP kunna sätta en giltighetstid på 1h medan en annan inte har någon giltighetstid, vilket man som SP då måste hantera.
<saml2:Conditions NotOnOrAfter="2018-06-12T18:25:57.701Z">
AuthnStatement → AuthnInstant
Tidpunkt då autentisering skedde i IdP:n
<saml2:AuthnStatement AuthnInstant="2018-06-12T17:25:53.875Z" SessionIndex="ecdba7f0-dafd-42ae-8de1-d38b7f2e2946">
AuthnStatement → SessionNotOnOrAfter
Anger IdP sessionens giltighetstid.
Sätts ej av Inera IdP pga dess inverkan på SP'ns sessionshantering i vissa SP produkter/ramverk (ex. Shibboleth SP), där SP sessionen avslutas då den angivna tiden passerats.
Exempel
IdP Metadata
Notera att detta enbart är ett exempel. Korrekt metadata måste inhämtas från aktuell IdP.
<md:EntityDescriptor entityID="https://auth.dev.inera.test:8443/saml" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:idpdisco="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> <ds:Reference URI=""> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <ds:DigestValue>9I2CWL2vgsDRB0gaQsCq8cdMWUDuY99m7Qgh0imvHv0=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>jQaDxr... </ds:SignatureValue> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate>MIIDtj...</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </ds:Signature> <md:Extensions> <mdattr:EntityAttributes> <saml2:Attribute Name="urn:oasis:names:tc:SAML:attribute:assurance-certification" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue>http://id.sambi.se/loa/loa2</saml2:AttributeValue> <saml2:AttributeValue>http://id.sambi.se/loa/loa3</saml2:AttributeValue> <saml2:AttributeValue>http://id.sambi.se/loa/loa4</saml2:AttributeValue> </saml2:Attribute> </mdattr:EntityAttributes> </md:Extensions> <md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <md:KeyDescriptor use="signing"> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate>MIIFZj...</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </md:KeyDescriptor> <md:KeyDescriptor use="signing"> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate>MIID2...</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </md:KeyDescriptor> <md:ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://auth.dev.inera.test:8443/saml/artifact/SOAP" index="0" isDefault="true"/> <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://auth.dev.inera.test:8443/saml/slo/HTTP-Redirect"/> <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://auth.dev.inera.test:8443/saml/slo/HTTP-Artifact"/> <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://auth.dev.inera.test:8443/saml/slo/HTTP-POST"/> <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat> <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat> <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://auth.dev.inera.test:8443/saml/sso/HTTP-Redirect"/> <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://auth.dev.inera.test:8443/saml/sso/HTTP-Artifact"/> <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://auth.dev.inera.test:8443/saml/sso/HTTP-POST"/> <saml2:Attribute FriendlyName="commissionHsaId" Name="http://sambi.se/attributes/1/commissionHsaId" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/> <saml2:Attribute FriendlyName="commissionName" Name="http://sambi.se/attributes/1/commissionName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/> <saml2:Attribute FriendlyName="commissionPurpose" Name="http://sambi.se/attributes/1/commissionPurpose" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/> <saml2:Attribute FriendlyName="commissionRight" Name="http://sambi.se/attributes/1/commissionRight" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/> <saml2:Attribute FriendlyName="employeeHsaId" Name="http://sambi.se/attributes/1/employeeHsaId" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/> <saml2:Attribute FriendlyName="givenName" Name="http://sambi.se/attributes/1/givenName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/> ... </md:IDPSSODescriptor> </md:EntityDescriptor>
SP Metadata
Notera att detta enbart är ett exempel. Korrekt metadata måste sammanställas av den egna SP'n med dess aktuella uppgifter.
<md:EntityDescriptor entityID="https://sp.dev.inera.test:8881" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:idpdisc="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> <md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <md:Extensions> <idpdisc:DiscoveryResponse Binding="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" Location="https://sak.ost.se:443/spadmin" index="0" isDefault="true"/> </md:Extensions> <md:KeyDescriptor use="signing"> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate>MIIFZjCCB...</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </md:KeyDescriptor> <md:ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://sp.dev.inera.test:8881/api/saml/artifact/SOAP" index="1" isDefault="true"/> <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://sp.dev.inera.test:8881/api/saml/slo/HTTP-Artifact"/> <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://sp.dev.inera.test:8881/api/saml/slo/HTTP-POST"/> <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat> <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://sp.dev.inera.test:8881/api/saml/sso/HTTP-POST" index="1" isDefault="true"/> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://sp.dev.inera.test:8881/api/saml/sso/HTTP-Artifact" index="2"/> <md:AttributeConsumingService index="0" isDefault="true"> <md:ServiceName xml:lang="sv">Lite attribut</md:ServiceName> <md:RequestedAttribute FriendlyName="authnMethod" Name="urn:sambi:names:attribute:authnMethod" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/> <md:RequestedAttribute FriendlyName="x509IssuerName" Name="http://www.w3.org/2000/09/xmldsig#x509IssuerName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/> <md:RequestedAttribute FriendlyName="x509SubjectName" Name="http://www.w3.org/2000/09/xmldsig#x509SubjectName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/> <md:RequestedAttribute FriendlyName="levelOfAssurance" Name="urn:sambi:names:attribute:levelOfAssurance" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/> </md:AttributeConsumingService> <md:AttributeConsumingService index="1"> <md:ServiceName xml:lang="sv">Mera attribut</md:ServiceName> <md:RequestedAttribute FriendlyName="employeeHsaId" Name="http://sambi.se/attributes/1/employeeHsaId" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/> <md:RequestedAttribute FriendlyName="givenName" Name="http://sambi.se/attributes/1/givenName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/> <md:RequestedAttribute FriendlyName="surname" Name="http://sambi.se/attributes/1/surname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/> <md:RequestedAttribute FriendlyName="systemRole" Name="http://sambi.se/attributes/1/systemRole" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/> <md:RequestedAttribute FriendlyName="organizationIdentifier" Name="http://sambi.se/attributes/1/organizationIdentifier" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/> <md:RequestedAttribute FriendlyName="organizationName" Name="http://sambi.se/attributes/1/organizationName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/> <md:RequestedAttribute FriendlyName="authnMethod" Name="urn:sambi:names:attribute:authnMethod" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/> <md:RequestedAttribute FriendlyName="x509IssuerName" Name="http://www.w3.org/2000/09/xmldsig#x509IssuerName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/> <md:RequestedAttribute FriendlyName="x509SubjectName" Name="http://www.w3.org/2000/09/xmldsig#x509SubjectName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/> <md:RequestedAttribute FriendlyName="levelOfAssurance" Name="urn:sambi:names:attribute:levelOfAssurance" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/> </md:AttributeConsumingService> </md:SPSSODescriptor> <md:Organization> <md:OrganizationName xml:lang="sv">Test SP</md:OrganizationName> <md:OrganizationDisplayName xml:lang="sv">Test SP</md:OrganizationDisplayName> <md:OrganizationURL xml:lang="sv">https://sp.dev.inera.test:8881/sp/saml</md:OrganizationURL> </md:Organization> <md:ContactPerson contactType="support" xml:lang="sv"> <md:Company>CGI</md:Company> <md:GivenName>Anders</md:GivenName> <md:SurName>Andersson</md:SurName> <md:EmailAddress>anders.andersson@example.com</md:EmailAddress> <md:TelephoneNumber>0701234567</md:TelephoneNumber> </md:ContactPerson> <md:ContactPerson contactType="technical" xml:lang="sv"> <md:Company>CGI</md:Company> <md:GivenName>Anders</md:GivenName> <md:SurName>Andersson</md:SurName> <md:EmailAddress>anders.andersson@example.com</md:EmailAddress> <md:TelephoneNumber>0701234567</md:TelephoneNumber> </md:ContactPerson> </md:EntityDescriptor>
Autentiseringsbegäran
Notera att detta enbart är ett exempel. Korrekt AuthnRequest måste sammanställas av SP'n med för den korrekt uppgifter som matchar dessa tidigare registrerade metadata.
<saml2p:AuthnRequest Destination="https://auth.dev.inera.test:8443/saml/sso/HTTP-Redirect" ForceAuthn="false" ID="219c3745-4399-4366-82ef-ebc92f3af88f" IssueInstant="2018-06-13T05:51:17.122Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" AttributeConsumingServiceIndex="0"> <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://sp.dev.inera.test:8881</saml2:Issuer> <saml2p:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/> <saml2p:RequestedAuthnContext Comparison="exact"> <saml2:AuthnContextClassRef xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">http://id.sambi.se/loa/loa3</saml2:AuthnContextClassRef> </saml2p:RequestedAuthnContext> </saml2p:AuthnRequest>
Autentiseringssvar
Notera att detta enbart är ett exempel. Svaret kommer vara baserat på aktuell SP's AuthnRequest i kombination med dessa metadata, och för IdP'n gällande uppgifter.
<saml2p:Response Destination="https://sp.dev.inera.test:8881/api/saml/sso/HTTP-POST" ID="_429608f164c7d54a3ff6fd24717312894416d804316ce2be22b3a5cb448a" InResponseTo="219c3745-4399-4366-82ef-ebc92f3af88f" IssueInstant="2018-06-13T05:52:36.810Z" Version="2.0" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://auth.dev.inera.test:8443/saml</saml2:Issuer> <saml2p:Status> <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> </saml2p:Status> <saml2:Assertion ID="_65fe31566c29c13ece81904bdbe0d5ca20fb187394e893603aeb2e01ebe9" IssueInstant="2018-06-13T05:52:36.812Z" Version="2.0" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://auth.dev.inera.test:8443/saml</saml2:Issuer> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> <ds:Reference URI="#_65fe31566c29c13ece81904bdbe0d5ca20fb187394e893603aeb2e01ebe9"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <ec:InclusiveNamespaces PrefixList="xsd" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <ds:DigestValue>bdYp4d/01W7JsbC7Ga9UugSX99YZK6NO71CHJGAMFII=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>OtuRPSg... </ds:SignatureValue> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate>MIIDtj...</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </ds:Signature> <saml2:Subject> <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">9c01e3aa-3046-45d2-a0c7-288842cfb50b</saml2:NameID> <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml2:SubjectConfirmationData InResponseTo="219c3745-4399-4366-82ef-ebc92f3af88f" NotOnOrAfter="2018-06-13T05:53:36.828Z" Recipient="https://sp.dev.inera.test:8881/api/saml/sso/HTTP-POST"/> </saml2:SubjectConfirmation> </saml2:Subject> <saml2:Conditions NotOnOrAfter="2018-06-13T06:52:36.824Z"> <saml2:AudienceRestriction> <saml2:Audience>https://sp.dev.inera.test:8881</saml2:Audience> </saml2:AudienceRestriction> </saml2:Conditions> <saml2:AttributeStatement> <saml2:Attribute FriendlyName="commissionHsaId" Name="http://sambi.se/attributes/1/commissionHsaId" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">SE111-UPPDRAG-JLL-TEKSYSADMIN</saml2:AttributeValue> </saml2:Attribute> ... </saml2:AttributeStatement> <saml2:AuthnStatement AuthnInstant="2018-06-13T05:52:09.114Z" SessionIndex="60fd0dae-8277-4a22-a797-3e2bee41318e"> <saml2:AuthnContext> <saml2:AuthnContextClassRef>http://id.sambi.se/loa/loa3</saml2:AuthnContextClassRef> </saml2:AuthnContext> </saml2:AuthnStatement> </saml2:Assertion> </saml2p:Response>
Referenser
Referens | Hänvisning |
---|---|
eGov | https://kantarainitiative.github.io/SAMLprofiles/eGovImplProfile.html |
SAML2Int | https://saml2int.org/profile/current/ |
SAML2Core | https://www.oasis-open.org/committees/download.php/35711/sstc-saml-core-errata-2.0-wd-06-diff.pdf |
SAML2Prof | https://www.oasis-open.org/committees/download.php/35389/sstc-saml-profiles-errata-2.0-wd-06-diff.pdf |
SAML2Bind | https://www.oasis-open.org/committees/download.php/35387/sstc-saml-bindings-errata-2.0-wd-05-diff.pdf |
SAML2Conf | https://www.oasis-open.org/committees/download.php/35393/sstc-saml-conformance-errata-2.0-wd-04-diff.pdf |
SAML2Err | |
SAML2Meta | https://www.oasis-open.org/committees/download.php/35391/sstc-saml-metadata-errata-2.0-wd-04-diff.pdf |
IdPDisco | |
MetaIOP | |
XMLEnc | |
XMLDSig | |
IAFAL | Identity Assurance Framework:Assurance Levels |
SAMBI-A attributspecifikation 1.0 | SAMBIattributspecifikation 1.0 |
SAMBI-T | SAMBI Tekniska krav |
Bilaga 1
Avsteg från arbetsunderlaget
Följande kapitel specificerar en delmängd avsteg, alternative tillägg, som är gjorda mot de båda profiler som ligger till grunden för denna profil. För tydliga specifikationer gällande denna profil, se respektive kapitel.
- [eGov2] definierar publicering samt erhålla SAML metadata från ”Well-Known Location” som SKALL, denna profil definierar detta som BÖR.
- [eGov2] definierar IdPDisco som SKALL. [SAML2Int] definierar endast att om den används SKALL
<idpdisco:DiscoveryResponse>
inkluderas i metadata för SP, denna profil definierar detta som KAN. - [SAML2Int] definierar att
<md:ContactPerson>
BÖR finnas. [eGov2] hanterar inte detta. Denna profil väljer att följa [SAMBI] och definierar detta som SKALL. - [eGov2] definierar HTTP-Artifact bindning som SKALL, denna profil har BÖR.
- [SAML2Int] BÖR, medans [eGov2] SKALL säkerställa att
<saml:AssertionConsumerServiceURL>
alt<saml:AssertionConsumingServiceIndex>
är korrekta enligt SPs metadata. Denna profil har SKALL. - [SAML2Int] definierar att
<saml2p:AuthnRequest>
SKALL INTE innehålla<saml2:Subject>
. Se kapitel namn-id format, samt autentiseringsbegäran för denna profils definition. - [SAML2Int] hanterar inte koordinerad utloggning. Denna profil rättar sig enligt [eGov2], förutom ställningstagande gällande propagering av utloggning.
- [eGov2] hänvisar till [SAML2Prof] som definierar att
<saml2p:ArtifactResolve>
BÖR signeras, denna profil definierar detta som SKALL.
Publik Information