Jämförda versioner

Gammal version 9

changes.mady.by.user Former user (Deleted)

Sparat den

jämfört med

Ny version Aktuell

changes.mady.by.user Former user (Deleted)

Sparat den

Nyckel

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

...

Version

Datum

Författare

Kommentar

0.8

 

Former user (Deleted)
Upprättad
1.0

 

Former user (Deleted)

Fastställd
12.12

 

Former user (Deleted) 

Lagt till Uppdaterad med information kring allCommissions och allEmployeeHsaIds, allEmployeeHsaIds och ADFS-metadata


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.

...

OBS! Notera att nedanstående enbart är exempel! Dvs det är inte dessa specifika attribut som styr om ett uppdragsval skall göras eller ej, utan dessa är enbart exempel.

 AttributeConsumingService AttributeConsumingService utan HSA-uppslag

Kodblock
languagexml
themeRDark
titleUtan 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>

...

Servicen för detta index innehåller enbart ett attribut som IdP:n skall leverera. Eftersom detta attribut inte kräver något HSA-uppslag kommer IdP:n att autentisera användaren utan att använda HSA-katalogen. Enbart de attribut som efterfrågas kommer tillhandahållas (försöka tillhandahållas).

 AttributeConsumingService AttributeConsumingService med HSA-uppslag

Kodblock
languagexml
themeRDark
titleMed 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 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.

Utan AttributeConsumingService (ADFS-metadata)

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. Med andra ord 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 i stunden då autentiseringen utförsoch angivna i förstudien. Listan på attributen kan dock ändras genom att ta kontakt med Ineras kundsupportskicka in en ny förstudie.

AuthnRequest

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 med HSA-uppslag

Kodblock
languagexml
themeRDark
titleMed HSA-uppslag
<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 AuthnRequest med uppdragsval

Kodblock
languagexml
themeRDark
titleMed uppdragsval
<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

Kodblock
languagexml
themeRDark
titleBeror på...
<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.

AuthnRequest med PrincipalSelection

Som SP finns möjligheten att på förhand göra ett specifikt val över vilket HSA-id, organisationsnummer, personnummer eller orgAffiliation som användaren ska bli inloggad med. Dess värden användas enskilt men också kombineras med varandra. När filtreringen görs 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.

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

Kodblock
languagexml
themeRDark
titlePrincipalSelection
<saml2p:Extensions>
    <psc:PrincipalSelection xmlns:psc="http://id.swedenconnect.se/authn/1.0/principal-selection/ns">
        <psc:MatchValue Name="http://sambi.se/attributes/1/employeeHsaId" xmlns:psc="http://id.swedenconnect.se/authn/1.0/principal-selection/ns">TSTNMT2321000156-10NG</psc:MatchValue>
        <psc:MatchValue Name="http://sambi.se/attributes/1/organizationIdentifier" xmlns:psc="http://id.swedenconnect.se/authn/1.0/principal-selection/ns">232100-0214</psc:MatchValue> 
    </psc:PrincipalSelection>
</saml2p:Extensions>