Jämförda versioner

Version Gammal version 6 Ny version 7
Ändringar gjorda av

Stefan Ehlert

Stefan Ehlert

Sparat den

Nyckel

  • Dessa rader lades till.
  • Denna rad togs bort.
  • Formateringen ändrades.

Expandera
titleVisa revisionshistorik

Version

Datum

Författare

Kommentar

0.1

 

Stefan Ehlert

  • Kopierad från tidigare version

Expandera
titleVisa innehållsförteckning
Innehållsförteckning
maxLevel2

Inledning

SAML attributstyrning innebär att en SP själv kan ange i sitt metadata (i kombination med sitt <AuthnRequest>) vilka attribut som efterfrågas för alla, eller en specifik autentisering.  Detta möjliggör att autentisering av en web-klient kan ske utan att man behöver göra ett uppdragsval, vilket exempelvis är användbart i de fall man bara har krav på identifiering och inte vill ha behörighetsstyrande attribut.

Detta kan uppnås genom att man nyttjar delar som är specificerade inom SAML och kombinerar data i entiteterna <IDPSSODescriptor>, <SPSSODescriptor> samt <AuthnRequest>.

En SP som förväntar sig ta emot attribut via <AttributeStatement> <AttributeStatement> från IdP:n måste ange 1..* <AttributeConsumingService> i sitt metadata. Detta ligger till grund för funktionaliteten som beskrivs nedan.

...

IdP:n specificerar i sitt metadata vilka attribut som den kan leverera. Nedanstående bild beskriver hur IdP-metadatat kan se ut med exempel på olika attribut som IdP:n kan tillhandahålla.

IDPSSODescriptor
Kodblock
theme
languagexmlRDark
titleIDPSSODescriptor
<saml:Attribute Name="urn:sambi:names:attribute:levelOfAssurance" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="levelOfAssurance"/>
<saml:Attribute Name="http://sambi.se/attributes/1/employeeHsaId" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="employeeHsaId"/>
<saml:Attribute Name="http://sambi.se/attributes/1/givenName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="givenName"/>
<saml:Attribute Name="http://sambi.se/attributes/1/systemRole" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="systemRole"/>
<saml:Attribute Name="http://sambi.se/attributes/1/commissionHsaId" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="assignmentHsaId"/>

...

AttributeConsumingService utan HSA-uppslag

Utan HSA-uppslag
Kodblock
title
languagexml
themeRDark
Utan HSA-uppslag
<AttributeConsumingService index="0" isDefault="true">
  <ServiceName xml:lang="sv">TestSP utan HSA-uppslag</ServiceName>
  <RequestedAttribute Name="urn:sambi:names:attribute:levelOfAssurance" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="levelOfAssurance"/>
</AttributeConsumingService>

Då denna <AttributeConsumingService> är  är satt till default så är det denna som kommer användas om SP:n i sitt <AuthnRequest> avstår från att ange vilken service som skall användas.

...

AttributeConsumingService med HSA-uppslag

Med HSA-uppslag
Kodblock
title
languagexml
themeRDark
Med HSA-uppslag
<AttributeConsumingService index="1">
  <ServiceName xml:lang="sv">TestSP med HSA-uppslag</ServiceName>
  <RequestedAttribute Name="urn:sambi:names:attribute:levelOfAssurance" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="levelOfAssurance"/>
  <RequestedAttribute Name="http://sambi.se/attributes/1/givenName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="givenName" isRequired="true"/>
  <RequestedAttribute Name="http://sambi.se/attributes/1/systemRole" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="systemRole"/>
</AttributeConsumingService>

Om denna <AttributeConsumingService> efterfrågas kommer IdP:n vara tvungen att utföra en HSA-slagning för att ta reda på värden för (åtminstone) "systemRole". Dock kommer inget uppdragsval göras då båda dessa attribut är oavhängiga av ett uppdrag. "givenName" har i detta fall tillägget "isRequired". Detta innebär att SP:n kräver att detta attribut finns med. Om IdP inte kan få fram detta attribut kommer den misslyckas med autentisering.

AttributeConsumingService med uppdragsval

Med uppdragsval
Kodblock
languagexml
themeRDark
titleMed uppdragsval
<AttributeConsumingService index="2">
  <ServiceName xml:lang="sv">TestSP med uppdragsval</ServiceName>
  <RequestedAttribute Name="urn:sambi:names:attribute:levelOfAssurance" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="levelOfAssurance"/>
  <RequestedAttribute Name="http://sambi.se/attributes/1/givenName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="givenName"/>
  <RequestedAttribute Name="http://sambi.se/attributes/1/systemRole" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="systemRole"/>
  <RequestedAttribute Name="http://sambi.se/attributes/1/commissionHsaId" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="assignmentHsaId"/>
</AttributeConsumingService>

I denna <AttributeConsumingService> begär SP:n attribut som enbart kan tillhandahållas då IdP:n ber aktören om ett uppdragsval. IdP:n kommer att göra sitt bästa för att tillhandahålla de attribut som SP:n begär, men då inget av attributen är angivna som "isRequired" så kommer autentisering lyckas, oavsett hur många attribut som SP:n får tillbaka. Det är senare upp till SP:n att avgöra vad man vill göra med biljetten.

AttributeConsumingService med samtliga uppdragsval

...

...

Samtliga uppdragsval utan val i IdP:n
Kodblock
languagexml
<AttributeConsumingService index="3">
  <ServiceName xml:lang="sv">TestSP med samtliga uppdragsval</ServiceName>
  <RequestedAttribute Name="urn:allCommissions" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="allCommissions"/>
</AttributeConsumingService>

Om man vill undvika uppdragsval i de fall som en användare har flera uppdrag och man vill ha all uppdragsinformation så kan man begära attributet allCommissions som i denna <AttributeConsumingService>. Detta kan vara användbart i situationer då SP:n vill ha användarens fullständiga behörighet. Detta kommer leda till att IdP:n gör en slagning mot HSA för att hämta samtliga uppdragsval för användaren. Däremot kommer IdP:n i detta scenario inte be användaren göra något uppdragsval. Samtliga uppdragsval kommer skickas tillbaka i biljetten.

AttributeConsumingService med samtliga uppdragsval med val i IdP:n

...

...

Samtliga uppdragsval med val i IdP:n
Kodblock
languagexml
<AttributeConsumingService index="4">
  <ServiceName xml:lang="sv">TestSP med samtliga uppdragsval och uppdragsval i IdP:n</ServiceName>
  <RequestedAttribute Name="urn:allCommissions" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="allCommissions"/>
  <RequestedAttribute Name="http://sambi.se/attributes/1/commissionHsaId" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="assignmentHsaId"/> 
</AttributeConsumingService>

I denna <AttributeConsumingService> begär SP:n attributen allCommissions och assignmentHsaId. I detta fall kommer IdP:n precis som ovan hämta samtliga uppdragsval från HSA och returnera dessa i biljetten. Dock så kommer användaren i det här fallet ändå behöva göra ett uppdragsval i IdP:n för att IdP:n ska kunna returnera ett värde för assignmentHsaId.

AttributeConsumingService med samtliga HSA ID:n

Samtliga HSA ID:n
Kodblock
languagexml
themeRDark
titleSamtliga HSA ID:n
<AttributeConsumingService index="5">
  <ServiceName xml:lang="sv">TestSP med samtliga HSA ID:n för användaren</ServiceName>
   <RequestedAttribute Name="urn:allEmployeeHsaIds" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="allEmployeeHsaIds"/>
</AttributeConsumingService>

Om man vill undvika uppdragsval i de fall som en användare har flera HSA ID:n och/eller flera uppdrag och man bara vill ha ett HSA ID:n kan man begära attributet allEmployeeHsaIds som visas i denna <AttributeConsumingService>. Då returneras en lista av HSA ID:n och SP:n kan då välja ett av dessa, t.ex. via en användardialog.

...

IdP:n stödjer även metadata där ingen <AttributeConsumingService> finns med. Dessa fall borde uteslutande vara när ADFS-metadata tillhandahålls för anslutning mot Ineras IdP. I dessa fall kan det anslutande systemet fortfarande begära attribut från IdP:n. Vid anslutningen måste en lista av attribut anges som det anslutande systemet vill ha i varje biljett efter lyckad autentisering. Det är denna lista av attribut som IdP:n alltid kommer försöka lösa in. I stunden då autentiseringen utförs finns alltså ingen möjlighet att begära ett annat set av attribut än de som finns registrerade hos oss och angivna i förstudien. Listan på attributen kan dock ändras genom att skicka in en ny förstudie.

...

För varje <AuthnRequest> så anger SP:n vilken av tidigare specificerade <AttributeConsumingService> som skall användas. Detta gör att en SP kan begära olika beteende för olika autentiseringar. SP:n väljer att ange attributet "AttributeConsumingServiceIndex" som skall kunna matchas mot ett index som finns i dess metadata. Nedan följer fyra exempel.

AuthnRequest utan HSA-uppslag

Utan HSA-uppslag
Kodblock
languagexml

...

<samlp:AuthnRequest xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute"
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    ForceAuthn="false" IsPassive="false" ProviderName="Sp Example Name"
    ID="ID850325636986645032969715339748802383986121801227" Version="2.0"
    IssueInstant="2013-03-21T09:31:17.235Z" Destination="https://auth.dev.inera.test:443/saml/HTTP-Redirect"
    Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
	AttributeConsumingServiceIndex="0">

SP:n skickar in att "index=0" skall nyttjas. Detta mappar i våra exempel ovan mot att HSA-uppslag inte kommer göras.

AuthnRequest med HSA-uppslag

Med HSA-uppslag
Kodblock
languagexml

...

...

<samlp:AuthnRequest xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute"
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    ForceAuthn="false" IsPassive="false" ProviderName="Sp Example Name"
    ID="ID850325636986645032969715339748802383986121801227" Version="2.0"
    IssueInstant="2013-03-21T09:31:17.235Z" Destination="https://auth.dev.inera.test:443/saml/HTTP-Redirect"
    Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
	AttributeConsumingServiceIndex="1">

SP'n skickar in att "index=1" skall nyttjas. Detta mappar i våra exempel ovan mot att HSA-uppslag kommer göras.

AuthnRequest med uppdragsval

Med uppdragsval
Kodblock
languagexml

...

<samlp:AuthnRequest xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute"
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    ForceAuthn="false" IsPassive="false" ProviderName="Sp Example Name"
    ID="ID850325636986645032969715339748802383986121801227" Version="2.0"
    IssueInstant="2013-03-21T09:31:17.235Z" Destination="https://auth.dev.inera.test:443/saml/HTTP-Redirect"
    Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
	AttributeConsumingServiceIndex="2">

SP'n skickar in att "index=2" skall nyttjas. Detta mappar i våra exempel ovan mot att uppdragsval kommer krävas.

AuthnRequest utan index

Beror på...
Kodblock
languagexml

...

...

<samlp:AuthnRequest xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute"
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    ForceAuthn="false" IsPassive="false" ProviderName="Sp Example Name"
    ID="ID850325636986645032969715339748802383986121801227" Version="2.0"
    IssueInstant="2013-03-21T09:31:17.235Z" Destination="https://auth.dev.inera.test:443/saml/HTTP-Redirect"
    Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified">

Här har skickar SP:n inte med något index. I exemplen ovan så leder detta till att "index=0" kommer att användas (dvs utan HSA-uppslag), eftersom "index=0" var satt som default.

Förval av principalen

Som SP finns möjligheten att på förhand ange information om användaren som inloggningen ska slutföras med. Informationen skickas in som Extension i AuthnRequesten och benämns PrincipalSelection. Se dokumentationen hos DIGG över hur PrincipalSelection fungerar och hur det är tänkt att användas. IdP stödjer idag förval av personnummer, tjänste-id, organisations-id, organisationsnummer, organisationstillhörighet eller medarbetaruppdrags-id. Dessa värden kan användas enskilt men också kombineras med varandra. IdP ser de tillhandahållna uppgifter som tvingande uppgifter som måste uppfyllas för att slutföra inloggningen. Vidare så gäller att ifall flera av dessa principal-fält specifierats måste samtliga uppfyllas, det räcker alltså inte ifall bara något eller några av principal-värden matchar. Skulle det visa sig att användarens uppgifter inte stämmer överens med det som skickats via PrincipalSelection kommer inloggningen markeras som misslyckad.

Under filtreringen försöker IdP:n göra ett val automatiskt baserad på den informationen som tagits emot i den AuthnRequest som skickats in. Om det är möjligt kan alltså exempelvis ett specifikt tjänste-id pekas ut och användaren slipper göra ett aktivt val i IdP:n. Om den angivna informationen inte är tillräckligt precis för att göra ett automatiskt val kommer användaren presenteras med tjänste-id- organisations- eller medarbetaruppdragsväljaren i IdP:ns publika användargränssnitt. I väljaren presenteras endast alternativen som på förhand har filtrerats med hjälp av de inskickade värden i PrincipalSelection.

Attribut som används i syfte att kunna förvälja principalen ändrar inte beteendet även om attributet har isRequired-flaggan specifierat i SP:ns SAML metadata. Detta för att förenkla logiken och få ett konsistent beteende för hur förvalet fungerar. Oavsett om "true" eller "false" återfinns i isRequired-flaggan kommer inloggningen misslyckas om inte IdP hittar matchande uppgifter om identiteten eller medarbetaruppdragen.

Värt att notera är att attributen som kan skickas in via PrincipalSelection inte måste återfinnas bland de begärda attributen i det inlästa SAML metadatat för SP:n. Denna lösa koppling möjliggör således att en SP kan styra förvalet av principalen utan att samtidigt också begära dessa attribut i den resulterande SAML-biljetten. Ett sådant exempel skulle kunna se ut som följer: SP:ns metadata specifierar att man begär attributet commissionName och commissionPurpose. SP:n väljer att göra ett förval av principalen genom att skicka in ett organisationsnummer i PrincipalSelection. Den resulterande SAML-biljetten innehåller commissionName och commissionPurpose, där medarbetaruppdraget som dessa uppgifter kommer ifrån tillhör det inskickade organisationsnumret.

Attribut

De värden som avläses i IdP:n för PrincipalSelection är:

Attribut (psc:MatchValue)

Används för

Format

urn:credential:personalIdentityNumber

Validering av personidentifierare

<psc:MatchValue Name="urn:credential:personalIdentityNumber" xmlns:psc="http://id.swedenconnect.se/authn/1.0/principal-selection/ns">personalIdentityNumber</psc:MatchValue>

http://sambi.se/attributes/1/personalIdentityNumber

Validering av personidentifierare

<psc:MatchValue Name="http://sambi.se/attributes/1/personalIdentityNumber" xmlns:psc="http://id.swedenconnect.se/authn/1.0/principal-selection/ns">personalIdentityNumber</psc:MatchValue>

http://sambi.se/attributes/1/employeeHsaId

Filtrering av tjänste-id

<psc:MatchValue Name="http://sambi.se/attributes/1/employeeHsaId" xmlns:psc="http://id.swedenconnect.se/authn/1.0/principal-selection/ns">employeeHsaId</psc:MatchValue>

http://sambi.se/attributes/1/commissionHsaId

Filtrering av medarbetaruppdrag

<psc:MatchValue Name="http://sambi.se/attributes/1/commissionHsaId" xmlns:psc="http://id.swedenconnect.se/authn/1.0/principal-selection/ns">commissionHsaId</psc:MatchValue>

urn:orgAffiliation

Filtrering av medarbetaruppdrag

<psc:MatchValue Name="urn:orgAffiliation" xmlns:psc="http://id.swedenconnect.se/authn/1.0/principal-selection/ns">employeeHsaId@organizationIdentifier</psc:MatchValue>

http://sambi.se/attributes/1/organizationIdentifier

Filtrering av medarbetaruppdrag

<psc:MatchValue Name="http://sambi.se/attributes/1/organizationIdentifier" xmlns:psc="http://id.swedenconnect.se/authn/1.0/principal-selection/ns">organizationIdentifier</psc:MatchValue>

Övriga attribut kommer att ignoreras. Attributet SAML Subject kan användas för att förmedla personidentifierare med samma påföljder som om PrincipalSelection används. Endast ETT sätt ska användas för att förmedla Personidentifierare. Endast ETT sätt ska användas för att förmedla tjänste-id och organisationsidentifierare.

Exempel på användningsfall

Låt oss anta att användaren har en uppsättning i HSA som grovt förenklat ser ut som strukturen nedan. Vi antar också att användaren använder sitt eget SITHS eID med personnummret som finns speficierat nedan.

För att hålla exemplen enkla används enbart employeeHsaId, commissionHsaId och personalIdentityNumber som de attribut som begärs via SP:ns SAML metadata. Kom ihåg att som tidigare beskrivet så finns det ingen koppling mellan attributen från SAML metadata och attributen som matas in via PrincipalSelection. Exemplen i tabellen är bara ett litet urval av möjliga scenarion och täcker inte alla användningsfall eller kombinationer.

  • Person: 19121212-1212

    • Tjänste-id: employeeHsaId 111

      • Medarbetaruppdrag: commissionHsaId aaa, organisationsnummer 12345

      • Medarbetaruppdrag: commissionHsaId bbb, organisationsnummer 12345

    • Tjänste-id: employeeHsaId 222

      • Medarbetaruppdrag: commissionHsaId ccc, organisationsnummer 12345

    • Tjänste-id: employeeHsaId 333

      • Medarbetaruppdrag: commissionHsaId ddd, organisationsnummer 67890

    • Tjänste-id: employeeHsaId 444 (saknar medarbetaruppdrag)

Expandera

Inmatning till förval

Resultat

employeeHsaId: 111

Ingen användarinteraktion krävs. SAML-biljett erhålles med employeeHsaId 111.

employeeHsaId: 444

Ingen användarinteraktion krävs. SAML-biljett erhålles med employeeHsaId 444.

employeeHsaId: 999

Inloggningen misslyckas, inget giltigt tjänste-id hittas.

commissionHsaId: bbb

Ingen användarinteraktion krävs. SAML-biljett erhålles med employeeHsaId 111.

commissionHsaId: zzz

Inloggningen misslyckas, inget giltigt medarbetaruppdrag hittas.

organisationIdentifier: 12345

Användarinteraktion krävs, användaren presenteras med tjänste-id-väljaren och får välja bland tjänste-id:n 111 och 222. SAML-biljett erhålles med det valda employeeHsaId.

employeeHsaId: 333

organizationIdentifier: 67890

Ingen användarinteraktion krävs. SAML-biljett erhålles med employeeHsaId 333.

employeeHsaId: 333

organizationIdentifier: 12345

Inloggningen misslyckas, inget matchande medarbetaruppdrag hittas.

personalIdentityNumber: 19000101-0001

Inloggningen misslyckas, personnummer matchar inte identiteten.

Expandera

Inmatning till förval

Resultat

commissionHsaId: ccc

Ingen användarinteraktion krävs. SAML-biljett erhålles med commissionHsaId ccc.

employeeHsaId: 111

Användarinteraktion krävs, användaren presenteras med medarbetaruppdrags-väljaren och får välja bland medarbetaruppdrag aaa och bbb. SAML-biljett erhålles med det valda commissionHsaId.

employeeHsaId: 444

commissionHsaId har isRequired="false": Inloggningen lyckas. Tom SAML-biljett erhålles.

commissionHsaId har isRequired="true": Inloggningen misslyckas. IdP kan inte uppfylla krav på commissionHsaId.

employeeHsaId: 999

Inloggningen misslyckas, inget giltigt tjänste-id hittas.

organizationIdentifier: 12345

Användarinteraktion krävs, användaren presenteras med medarbetaruppdrags-väljaren och får välja bland medarbetaruppdrag aaa, bbb och ccc. SAML-biljett erhålles med det valda commissionHsaId.

employeeHsaId: 222

organizationIdentifier: 12345

Ingen användarinteraktion krävs. SAML-biljett erhålles med commissionHsaId ccc.

personalIdentityNumber: 19121212-1212

Användarinteraktion krävs, användaren presenteras med medarbetaruppdrags-väljaren och får välja bland medarbetaruppdrag aaa, bbb, ccc, ddd. SAML-biljett erhålles med det valda commissionHsaId.

Expandera

Inmatning till förval

Resultat

personalIdentityNumber: 19121212-1212

Ingen användarinteraktion krävs. SAML-biljett erhålles med personalIdentityNumber 19121212-1212.

personalIdentityNumber: 19000101-0001

Inloggningen misslyckas, personnummer matchar inte identiteten.

employeeHsaId: 111

Ingen användarinteraktion krävs. SAML-biljett erhålles med personalIdentityNumber 19121212-1212.

commissionHsaId: aaa

Ingen användarinteraktion krävs. SAML-biljett erhålles med personalIdentityNumber 19121212-1212.

Förval av principalen i praktiken

I exemplet nedan förväntas användaren bli inloggad med personnummer 194211196979, tjänste-id:t TSTNMT2321000156-10NG för organisationen med organisationsnumret 232100-0214.

PrincipalSelection
Kodblock
languagexml

...

<saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
  Destination="https://idp.dev.inera.test:8443/saml/sso/HTTP-POST"
  ForceAuthn="false"
  ID="a4c722ff-4a14-4719-9c11-a36a47c00139"
  IsPassive="false"
  IssueInstant="2023-10-19T08:50:52.279Z"
  ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
  Version="2.0">
  <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://sp.dev.inera.test:8881</saml2:Issuer>
  <saml2p:Extensions>
    <psc:PrincipalSelection xmlns:psc="http://id.swedenconnect.se/authn/1.0/principal-selection/ns">
      <psc:MatchValue Name="http://sambi.se/attributes/1/personalIdentityNumber" xmlns:psc="http://id.swedenconnect.se/authn/1.0/principal-selection/ns">194211196979</psc:MatchValue>
      <psc:MatchValue Name="urn:orgAffiliation" xmlns:psc="http://id.swedenconnect.se/authn/1.0/principal-selection/ns">SE2321000040-4C08@2321000040</psc:MatchValue>  
    </psc:PrincipalSelection>
  </saml2p:Extensions>
</saml2p:AuthnRequest>