Revisionshistorik
Version | Datum | Författare | Kommentar |
---|---|---|---|
0.8 |
| Upprättad | |
1.0 |
| Fastställd | |
2.2 |
| Uppdaterad med information kring allCommissions, allEmployeeHsaIds och ADFS-metadata |
...
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. 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.
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 utan index
Kodblock | ||||||
---|---|---|---|---|---|---|
| ||||||
<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 | ||||||
---|---|---|---|---|---|---|
| ||||||
<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> |