AuthnRequest utan index

<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, medarbetaruppdrags-id, organisations-id, organisationsnummer eller orgAffiliationorganisationstillhörighet. 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 eller medarbetaruppdragsväljaren i IdP:ns GUI. I väljaren presenteras endast alterantiven 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 isRequred-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.

Notera även att filtrering på organisation (orgAffiliation, organizationIdentifier) endast kan leda till en lyckad inloggning om användaren i fråga har medarbetaruppdrag konfigurerat på sig. Det är en känd begränsning då uppgifter om organisationstillhörighet endast erhålls via medarbetaruppdrag genom HSA. Som ett exempel så skulle alltså inloggningen misslyckas i fallet då en organisation matas in i förvalet av principalen men användaren saknar medarbetaruppdrag helt och hållet (eller även när inget av medarbetaruppdragen tillhör den inmatade organisationen).

Attribut

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

Mer information om hur denna mekanism fungerar finns på denna här: IdP:ns publika användargränssnitt

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.