Attributstyrning SAML

Revisionshistorik

Version	Datum	Författare	Kommentar
0.8	13 juni 2018	Former user (Deleted)	Upprättad
1.0	25 okt. 2018	Former user (Deleted)	Fastställd

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>.

I Inera IdP är det ett SKALL krav att en SP anger 1..* <AttributeConsumingService> i sitt metadata, och det är detta som ligger till grund för funktionaliteten som beskrivs nedan.

Specifikation enligt SAML v2.0

IDPSSODescriptor (IdP-metadata)

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

<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"/>

SPSSODescriptor (SP-metadata)

En SP kan välja att lägga till 1..* <AttributeConsumingService> i sitt metadata som sub-element till <SPSSODescriptor>. Dessa kommer sedan via sitt index matchas mot angivet värde i ett <AuthnRequest>. Baserat på vilka attribut som en SP begär vid ett specifikt autentiseringstillfälle kommer IdP:n avgöra om uppdragsval (eller HSA-uppslag generellt) behöver göras eller ej.

Nedan följer tre exempel som en SP kan ange för att kunna uppnå olika sorters attributuppslag i sin autentisering av användare.

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.

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 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.

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).

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.

Med 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.

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.

Utan 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="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.

Med 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.

Med 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.

Beror 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.