IntroduktionDenna 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 NotationTjä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 namnrymdFö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# |
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> . SP SKALL använda funktionscertifikat som är godkänd för anslutning till IdP, se Guide till IdP. 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"> .
- 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> . - 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".
Byte av signeringsnyckelFör att kunna genomföra sömlösa nyckelbyten mot IdP:n behöver SP:n ha möjlighet att generera ett SP metadata som innehåller två <KeyDescriptor> på samma gång. Rent praktiskt går ett sådant nyckelbyte till såhär: - SP har redan ett inläst metadata hos IdP med en befintlig nyckel
- SP tar fram ett nytt metadata där både den nya och den gamla nyckel finns med som exemplet nedan visar
- SP skickar metadatat till IdP för inläsning
- IdP läser in metadata
- SP genomför nyckelbytet
- (Optionellt) SP tar fram ett nytt metadata där enbart den nya nyckel finns med
- (Optionellt) SP skickar metadatat med endast den nya nyckeln till IdP för inläsning
- (Optionellt) IdP läser in metadata
Kodblock |
---|
language | xml |
---|
theme | Eclipse |
---|
title | Exempel för metadata vid övergång till ny nyckel |
---|
| <KeyDescriptor use="signing">
<X509Data>
<X509Certificate>Certifikat 1 ..... </X509Certificate>
</X509Data>
</KeyDescriptor>
<KeyDescriptor use="signing">
<X509Data>
<X509Certificate>Certifikat 2 ..... </X509Certificate>
</X509Data>
</KeyDescriptor> |
IdP SKALL stödja samtliga nedanstående namn-id format, och SP SKALL stödja minst ett. Format | Beskrivning |
---|
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
| 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 attributSe attributspecifikation. Egenskaper när uppgifter i attributkälla saknasFö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 IdentifieringDetta 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.
AutentiseringBegäranBindningar 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ållSP 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 ". SvarBindningar 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).
UnderskriftTjä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.
SvarBindning 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ärdareIdP'n SKALL stödja följande utfärdare av användarcertifikat. Felhantering - SAML statusVid 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 <StatusCode> | 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 statuskoderSekundär <StatusCode> | 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ödAutentiseringEn 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-initieradMed 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 Kodblock |
---|
language | text |
---|
theme | RDark |
---|
title | Enbart EntityID |
---|
| https://idp.ineratest.org/saml/unsolicited/sso?providerId=https%3A%2F%2Ftest.example.se%3A443%2Fsp%2Fsaml |
Kodblock |
---|
language | text |
---|
theme | RDark |
---|
title | Med AssertionConsumerServiceURL |
---|
| 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 |
Kodblock |
---|
language | text |
---|
theme | RDark |
---|
title | Med RelayState |
---|
| https://idp.ineratest.org/saml/unsolicited/sso?providerId=https%3A%2F%2Ftest.example.se%3A443%2Fsp%2Fsaml&target=ss%3Amem%3A6aa181259dc9ba41725ce239fe77925c430e0132cd92076dc16ebbe9806866c7 |
AnvisningstjänstHanteras av SAMBI för anslutna IdP:er/SP:ar enligt tekniska kraven under sambi anslutningsavtal. Ange vilka attribut som SP efterfrågarI 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 biljettenEn saml-biljett innehåller ett flertal tids-stämplar som man som SP bör känna till. Assertion → IssueInstantTidpunkt då saml-biljetten skapats av IdP:n Kodblock |
---|
| <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 → notOnOrAfterSubjectConfirmation 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) Kodblock |
---|
| <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 → notOnOrAfterIdP: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.
Kodblock |
---|
| <saml2:Conditions NotOnOrAfter="2018-06-12T18:25:57.701Z"> |
AuthnStatement → AuthnInstantTidpunkt då autentisering skedde i IdP:n Kodblock |
---|
| <saml2:AuthnStatement AuthnInstant="2018-06-12T17:25:53.875Z" SessionIndex="ecdba7f0-dafd-42ae-8de1-d38b7f2e2946"> |
AuthnStatement → SessionNotOnOrAfterAnger 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. ExempelNotera att detta enbart är ett exempel. Korrekt metadata måste inhämtas från aktuell IdP. Kodblock |
---|
| <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> |
Notera att detta enbart är ett exempel. Korrekt metadata måste sammanställas av den egna SP'n med dess aktuella uppgifter. Kodblock |
---|
| <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äranNotera 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. Kodblock |
---|
| <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> |
AutentiseringssvarNotera 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. Kodblock |
---|
| <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> |
ReferenserBilaga 1Avsteg från arbetsunderlagetFö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.
|