SAML 1.1

Security Assertion Markup Language (SAML) är en XML- standard för utbyte av autentiserings- och auktoriseringsdata mellan säkerhetsdomäner. SAML är en produkt från OASIS (organisation) Security Services Technical Committee .

SAML 1.1 ratificerades som en OASIS-standard i september 2003. De kritiska aspekterna av SAML 1.1 behandlas i detalj i de officiella dokumenten SAMLCore och SAMLBind. Om du är ny på SAML bör du förmodligen läsa det inledande SAML- ämnet först, och sedan SAMLOoverview-dokumentet från OASIS.

Innan SAML 1.1 antogs SAML 1.0 som en OASIS-standard i november 2002. SAML har genomgått en mindre (V1.1) och en större revision (V2.0) sedan V1.0, vilket i sig är ett relativt enkelt protokoll . SAML 1.0 är dock av mer än historiskt intresse, eftersom US Federal E-Authentication Initiative har antagit SAML 1.0 som sin kärnteknologi.

Versioner 1.0 och 1.1 av SAML är liknande. Se SAMLDiff för specifika skillnader mellan de två standarderna. Den här artikeln koncentrerar sig på SAML 1.1 eftersom det är en viktig standard som många andra standarder och implementeringar är beroende av.

Varning: Implementerare och driftsättare bör notera att alla kodexempel i den här artikeln är icke-normativa och endast i illustrationssyfte. Se OASIS SAML-specifikationer för normativa krav.

SAML 1.1 Påståenden

SAML- påståenden innehåller uttalanden som tjänsteleverantörer använder för att fatta beslut om åtkomstkontroll. Till exempel autentiseringsutlåtanden för tjänsteleverantören att huvudmannen verkligen autentiserade med identitetsleverantören vid en viss tidpunkt med hjälp av en viss autentiseringsmetod. Annan information om huvudmannen kan lämnas i ett autentiseringsutlåtande. I autentiseringsförklaringen nedan anges till exempel huvudmannens e-postadress till tjänsteleverantören: 

  
    
     
    
    
    
    
      
      
    
      
      
      
        
          
        
          
        
      
    
   <saml:Assertion  xmlns:saml=  "urn:oasis:names:tc:SAML:1.0:assertion"  MajorVersion=  "1"  MinorVersion=  "1"  AssertionID=  "buGxcG4gILg5NlocyLccDz6iXrUa"  Issuer=  "https://idp.example" /saml"  IssueInstant=  "2002-06-19T17:05:37.795Z"  >  <saml:Conditions  NotBefore=  "2002-06-19T17:00:37.795Z"  NotOnOrAfter=  "2002-06-1909T37:7:7.  />  <saml:AuthenticationStatement  AuthenticationMethod=  "urn:oasis:names:tc:SAML:1.0:am:password"  AuthenticationInstant=  "2002-06-19T17:05:17.706Z"  >  <saml:Subject>  <saml  Format :NameI  =   "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"  >  [email protected]  </saml:NameIdentifier>  <saml:SubjectConfirmation>  <saml:ConfirmationMethod>  urn:oasis:names: tc:SAML:1.0:cm:bearer  </saml:ConfirmationMethod>  </saml:SubjectConfirmation>  </saml:Subject>  </saml:AuthenticationStatement>  </saml:Assertion>

En e-postadress (som i exemplet ovan) kommer att räcka i ett stort antal situationer. I vissa fall behövs dock ytterligare information innan en tjänsteleverantör kan fatta ett beslut om åtkomstkontroll. Anta som ett exempel att studenter får tillgång till stipendiedata. En attributsats kan indikera huruvida huvudmannen har en anknytning till "student", som tjänsteleverantören använder för att tillåta eller neka åtkomst (resp.) till stipendieansökan: 

  
    
     
     
      
    
      
      
      
    
    
      
      
        
        
        
        
      
    
   <saml:Assertion  xmlns:saml=  "urn:oasis:names:tc:SAML:1.0:assertion"  MajorVersion=  "1"  MinorVersion=  "1"  Issuer=  "https://idp.example.org/saml"  .. .  >  <saml:Conditions  NotBefore=  "..."  NotAfter=  "..."  />  <saml:AuthenticationStatement  AuthenticationMethod=  "..."  AuthenticationInstant=  "..."  >  <saml:Subject>  ...  < /saml:Subject>  </saml:AuthenticationStatement>  <saml:AttributeStatement>  <saml:Subject>  ...  </saml:Subject>  <saml:Attribute  AttributeName=  "urn:mace:dir:attribute-def:eduPersonAffiliation"  AttributNamespace =  "urn:mace:shibboleth:1.0:attributeNamespace:uri"  >  <saml:AttributeValue>  medlem  </saml:AttributeValue>  <saml:AttributeValue >   elev </saml:AttributeValue> </saml  :AttributeValue>  <  /saml:AttributeStatement >  </saml:Assertion>

Attribut erhålls ofta från en LDAP- katalog, så konsekventa representationer av attribut över säkerhetsdomäner är avgörande.

I exemplet ovan, som visar hur en student kan få tillgång till en stipendieansökan, fungerar tjänsteleverantören både som en punkt för upprätthållande av policy och en punkt för policybeslut . I vissa situationer kan det vara att föredra att koppla policybeslutspunkten till identitetsleverantören. I det här fallet skickar tjänsteleverantören en URI till identitetsleverantören som hävdar ett tillståndsbeslutsuttalande som dikterar huruvida huvudmannen ska ges åtkomst till den säkrade resursen vid den givna URI:n. 

  
    
     
     
     
    
      
      
      
      
    
   <saml:Assertion  xmlns:saml=  "urn:oasis:names:tc:SAML:1.0:assertion"  MajorVersion=  "1"  MinorVersion=  "1"  Issuer=  "https://idp.example.org/saml"  .. .  >  <saml:Villkor  ...  />  <saml:AuthorizationDecisionStatement  Decision=  "Permit"  Resource=  "https://sp.example.com/confidential_report.html"  >  <saml:Subject>  ...  </saml: Ämne>  <saml:Action>  läs  </saml:Action>  </saml:AuthorizationDecisionStatement>  </saml:Assertion>

De tre påståendetyperna utesluter inte varandra. Till exempel kan både autentiseringssatser och attributsatser inkluderas i ett enda påstående (som visas ovan). Detta utesluter behovet av att göra efterföljande rundresor mellan tjänsteleverantören och identitetsleverantören.

SAML 1.1-protokoll

Ett SAML- protokoll är ett enkelt begäran-svar-protokoll. En SAML-begäran skickar ett SAML Request- element till en svarsperson: 

  
    
     
    
    
    
   <samlp:Request  xmlns:samlp=  "urn:oasis:names:tc:SAML:1.0:protocol"  MajorVersion=  "1"  MinorVersion=  "1"  RequestID=  "aaf23196-1773-2113-474a-fe114412ab72 =   "2006t "   IssueInstant  -07-17T22:26:40Z"  >  <!-- infoga andra SAML-element här -->  </samlp:Request>

På liknande sätt returnerar en SAML-svarare ett SAML- svarselement till förfrågaren: 

  
    
     
    
    
    
    
   <samlp:Response  xmlns:samlp=  "urn:oasis:names:tc:SAML:1.0:protocol"  MajorVersion=  "1"  MinorVersion=  "1"  ResponseID=  "b07b804c-7c29-ea16-7300-4f3d6f7928acTo1  =  "6aafponseTo1" InRes  -1773-2113-474a-fe114412ab72"   IssueInstant=  "2006-07-17T22:26:41Z"  >  <!-- infoga andra SAML-element här, inklusive påståenden --> <  /samlp:Response>

De bindningar och profiler som behövs för att påverka detta meddelandeutbyte beskrivs i följande avsnitt.

SAML 1.1 Bindningar

SAML 1.1 definierar formellt bara en protokollbindning , SAML SOAP-bindningen. En kompatibel SAML 1.1-implementering måste implementera SAML över SOAP över HTTP (en synkron protokollbindning). Andra transportmekanismer förutom HTTP är tillåtna, förutsatt att de protokolloberoende aspekterna av SAML SOAP-bindningen observeras (se avsnitt 3.1.2 i SAMLBind).

SAML 1.1 SOAP-bindningen är byggd ovanpå version 1.1 av SOAP (numreringen är en ren tillfällighet). En SAML-begärare lindar ett SAML Request- element i brödtexten i ett SOAP-meddelande. På liknande sätt returnerar en SAML-svarare ett SAML- svarselement i brödtexten i ett returnerat SOAP-meddelande. Om det finns ett fel, returnerar svararen en SOAP-felkod istället.

Alla SAML-märkningar måste inkluderas i SOAP-kroppen. SAML 1.1 definierar inga SAML-specifika SOAP-rubriker. En begärande kan fritt infoga vilka SOAP-rubriker den vill (även om inga krävs).

Kom ihåg att i SOAP 1.1 måste en SOAPAction HTTP-header inkluderas med varje HTTP-begäran (även om dess värde kan vara tomt). En SAML-begärare kan ge följande värde till SOAPAction -huvudet: 

SOAPAction: http://www.oasis-open.org/committees/security

En SAML-svarare får dock inte vara beroende av detta värde.

En säker anslutning krävs inte för SAML-förfrågningar och svar, men i de situationer där meddelandeintegritet och konfidentialitet krävs krävs HTTP över SSL 3.0 eller TLS 1.0 med ett certifikat på serversidan.

En SAML-svarare kan returnera ett "403 Forbidden"-svar när den vägrar att svara på en SAML-begärare. En responder måste returnera ett "500 Internal Server Error"-svar i händelse av ett SOAP-fel (ett SOAP-felelement måste också inkluderas). Annars returneras ett "200 OK"-svar, även i närvaro av ett SAML-bearbetningsfel. Ett sådant svar kommer att inkludera ett SAML- statuselement i SOAP-kroppen.

SAML 1.1-profiler

I allmänhet beskriver profiler de användningsfall och meddelandeutbyten som krävs för att slutligen överföra påståenden från en identitetsleverantör till en tjänsteleverantör. SAML 1.1 anger två SSO-profiler för webbläsare:

  1. Webbläsare/POST-profil
  2. Webbläsare/Artefaktprofil

Browser/POST-profilen förlitar sig på en "push"-operation som skickar ett SSO-påstående efter värde genom webbläsaren med hjälp av HTTP POST. Vi säger att identitetsleverantören "skjuter" påståendet till tjänsteleverantören.

Webbläsaren/artefaktprofilen använder en "pull"-mekanism. Profilen skickar i huvudsak ett SSO-påstående från identitetsleverantören till tjänsteleverantören genom referens (via webbläsaren som använder HTTP-omdirigering), som därefter avreferens via en back-channel-utbyte (dvs. tjänsteleverantören "drar" påståendet från identiteten leverantör som använder SAML över SOAP över HTTP).

Dessa profiler stöder enkel inloggning över flera domäner (SSO). Specifikationen definierar inga ytterligare profiler. SAML 1.1 stöder inte en profil för att säkra ett webbtjänstmeddelande och stöder inte heller en enskild utloggningsprofil.

Båda SAML 1.1-profilerna börjar vid överföringstjänsten mellan platser , som hanteras av identitetsleverantören. Hur huvudmannen kommer till förflyttningstjänsten i första hand dikteras inte av specifikationen. Se avsnitt 4.1 och 4.2 i SAMLOoverview för möjliga scenarier. I praktiken kommer en klient som får åtkomst till en säker resurs hos en tjänsteleverantör att omdirigeras till överföringstjänsten mellan platsen hos identitetsleverantören, men den exakta sekvensen av steg som krävs för att åstadkomma detta beskrivs inte i SAML 1.1. (Se avsnitt 4.3 i SAMLOoverview för några grova idéer i denna linje.) Detta scenario behandlas noggrant i SAML 2.0.

Efter att ha besökt överföringstjänsten mellan anläggningar, överförs huvudmannen till påstående konsumenttjänsten hos tjänsteleverantören. Exakt hur huvudmannen överförs från överföringstjänsten mellan platsen till tjänsten påstående konsument beror på vilken profil som används. I fallet med webbläsaren/artefaktprofilen används en omdirigering; i fallet med webbläsaren/POST-profilen utfärdar klienten en POST-begäran (med eller utan användaringripande).

För att påskynda bearbetningen av påstående konsumenttjänsten anges två separata webbadresser:

  1. Påstående konsument-URL (webbläsar-/POST-profil)
  2. Artefaktmottagarens URL (webbläsare/artefaktprofil)

Dessa och andra slutpunktsplatser kan registreras i metadatafiler. Exakt hur identitetsleverantören erhåller en betrodd metadatafil, eller på annat sätt bestämmer de betrodda slutpunktsplatserna för en viss tjänsteleverantör, är utanför omfattningen med avseende på SAML 1.1.

Observera att en SAML 1.1-identitetsleverantör som uppfyller kraven måste tillhandahålla en överföringstjänst mellan platsen. På samma sätt måste en SAML 1.1-tjänsteleverantör tillhandahålla en påstående konsumenttjänst.

Webbläsare/POST-profil

SAML 1.1 Browser/POST-profilen anger följande fyra (4) steg. Terminologin som används i den ursprungliga specifikationen har ändrats något för att överensstämma med SAML 2.0-specifikationen.

Meddelandeflödet börjar med en begäran riktad till IdP.

Begär Inter-site Transfer Service hos IdP

Huvudmannen (via en HTTP-användaragent) begär Inter-site Transfer Service hos identitetsleverantören:

 https://idp.example.org/TransferService?TARGET=  mål

där målet är den önskade resursen hos tjänsteleverantören, till exempel https://sp.example.com/home. Med andra ord, följande GET-begäran utfärdas av användaragenten över SSL/TLS: 

    GET  /TransferService?TARGET=target  HTTP  /  1.1 
 Host  :  idp.example.org

Profilen anger inte hur URL:en till överföringstjänsten (med TARGET -parametern) erhålls av användaragenten.

Svara med ett HTML-formulär

Inter-site Transfer Service returnerar ett HTML-dokument som innehåller ett FORM- element: 

  
 
 

   
         
 HTTP  /  1.1  200  OK  Content-Type  :  text/html  Content-Length  :  nnnn  ...  <  form  method  =  "post"  action  =  "https://sp.example.com/ACS/POST"  ...  >        <  input  type  =  "hidden"  name  =  "MÅL"  värde  =  "mål"  /> 
 <  input  type  =  "hidden"  name  =  "SAMLResponse"  värde  =  "''response''"  />  ...  <  input  type  =  "submit"  value  =  "Skicka"  />  </  form  >  ...

där TARGET -parametern har bevarats från steg 1. Värdet på SAMLResponse- parametern är base64-kodningen av ett SAML Response -element som följande: 

  
    
     
    
    
    
      
    
       
    
    
      
       
      
      
      
      
        
        
      
        
        
        
          
            
          
            
          
        
      
    
   <samlp:Response  xmlns:samlp=  "urn:oasis:names:tc:SAML:1.0:protocol"  MajorVersion=  "1"  MinorVersion=  "1"  ResponseID=  "_P1YaA+Q/wSM/t/8E3R8rNhcpPTM="  IssueInstant=  " 2002-06-19T17:05:37.795Z"  >  <ds:Signature  xmlns:ds=  "http://www.w3.org/2000/09/xmldsig#"  >  ...  </ds:Signature>  <samlp :Status>  <samlp:StatusCode  Value=  "samlp:Success"  />  </samlp:Status>  <saml:Assertion  xmlns:saml=  "urn:oasis:names:tc:SAML:1.0:assertion"  MajorVersion=  "1"  MinorVersion=  "1"  AssertionID=  "buGxcG4gILg5NlocyLccDz6iXrUa"  Issuer=  "https://idp.example.org/saml"  IssueInstant=  "2002-06-19T17:05:37.795Z="2 NotBe02-06s "  2  Notsaml  :  Condition  -19T17:00:37.795Z"  NotOnOrAfter=  "2002-06-19T17:10:37.795Z"  />  <saml:AuthenticationStatement  AuthenticationMethod=  "urn:oasis:names:tc:SAML:1.0:In  Authenticationstan  " 2002-06-19T17:05:17.706Z"  >  <saml:Subject>  <saml:NameIdentifier  Format=  "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"  >  [email protected]  </saml:NameIdentifier>  <saml:SubjectConfirmation>  <saml:ConfirmationMethod>  urn:oasis:names:tc:SAML:1.0:cm:bearer  </saml:ConfirmationMethod>  </saml:SubjectConfirmation>  </saml:Subject>  < /saml:AuthenticationStatement>  </saml:Assertion>  </samlp:Response>

SAML-svaret måste signeras digitalt av identitetsleverantören.

Viktigt: Det antas att huvudmannen redan har etablerat en säkerhetskontext hos identitetsleverantören, annars skulle Inter-site Transfer Service inte kunna tillhandahålla en autentiseringssats i SAML Response -elementet.

Begär Assertion Consumer Service hos SP

Användaragenten begär Assertion Consumer Service hos tjänsteleverantören:

  
 
 
 
 POST  /ACS/POST  HTTP  /  1.1  Host  :  sp.example.com  Content-Type  :  application/x-www-form-urlencoded  Content-Length  :  nnnn  TARGET=target&SAMLResponse=response

där värdena för parametrarna TARGET och SAMLResponse är hämtade från HTML-formuläret i steg 2.

Obs! För att automatisera inlämningen av formuläret kan följande JavaScript-rad visas var som helst på sidan:

       0  fönster  .  onload  =  funktion  ()  {  dokument  .  former  [  ].  skicka  ();  }

Detta förutsätter naturligtvis att sidan innehåller ett enda FORM- element ( forms[0] ) .

Svara på rektors begäran

Assertion Consumer Service förbrukar SAML Response- elementet, skapar en säkerhetskontext hos tjänsteleverantören och omdirigerar användaragenten till målresursen.

Webbläsare/Artefaktprofil

SAML 1.1 Browser/Artifact-profilen anger följande sex (6) steg. Terminologin som används i den ursprungliga specifikationen har ändrats något för att överensstämma med SAML 2.0-specifikationen.

Meddelandeflödet börjar med en begäran riktad till IdP.

Begär Inter-site Transfer Service hos IdP

Huvudmannen (via en HTTP-användaragent) begär Inter-site Transfer Service hos identitetsleverantören:

 https://idp.example.org/TransferService?TARGET=  mål

där målet är den önskade resursen hos tjänsteleverantören, till exempel https://sp.example.com/home. Med andra ord, följande GET-begäran utfärdas av användaragenten över SSL/TLS: 

    GET  /TransferService?TARGET=target  HTTP  /  1.1 
 Host  :  idp.example.org

Profilen anger inte hur URL:en till överföringstjänsten (med TARGET -parametern) erhålls av användaragenten.

Omdirigera till Assertion Consumer Service

Huvudmannen omdirigeras till Assertion Consumer Service hos tjänsteleverantören, det vill säga följande svar returneras till användaragenten:

  
 HTTP  /  1.1  302  hittad   plats  :  https://sp.example.com/ACS/Artifact?TARGET=target&SAMLart=artifact

där artefakt är en hänvisning till ett påstående som identitetsleverantören är villig att tillhandahålla på begäran.

Viktigt: Det antas att huvudmannen redan har etablerat en säkerhetskontext hos identitetsleverantören, annars skulle Inter-site Transfer Service inte kunna tillhandahålla ett autentiseringsutlåtande.

Begär Assertion Consumer Service hos SP

Användaragenten begär Assertion Consumer Service hos tjänsteleverantören:

 https://sp.example.com/ACS/Artifact?TARGET=  target  &SAMLart=  artefakt

där mål och artefakt är som tidigare. Med andra ord, följande GET-begäran utfärdas av användaragenten över SSL/TLS: 

    GET  /ACS/Artifact?TARGET=target&SAMLart=artifact  HTTP  /  1.1 
 Host  :  sp.example.com

Begär Artifact Resolution Service hos IdP

Assertion Consumer Service hos tjänsteleverantören påbörjar ett back-channel utbyte med Artifact Resolution Service hos identitetsleverantören. Ett SAML SOAP-meddelande är bundet till en HTTP POST-begäran:


  
  
  
    
      
       
      
      
      
      
    
  
 POST /ArtifactResolutionService HTTP/1.1 Värd: idp.example.org Content-Type: text/xml Content-Length: nnn SOAPAction: http://www.oasis-open.org/committees/security <SOAP  -ENV:Envelope  xmlns: SOAP-ENV=  "http://schemas.xmlsoap.org/soap/envelope/"  >  <SOAP-ENV:Header/>  <SOAP-ENV:Body>  <samlp:Request  xmlns:samlp=  "urn:oasis:names :tc:SAML:1.0:protocol"  MajorVersion=  "1"  MinorVersion=  "1"  RequestID=  "_192.168.16.51.1024506224022"  IssueInstant=  "2002-06-19T17:03:44.022Zacts>er  >  <samArtif:Asifacts artif  "  >  /samlp:AssertionArtifact>  </samlp:Request>  </SOAP-ENV:Body>  </SOAP-ENV:Envelope>

där artefakt tidigare skickades från identitetsleverantören till tjänsteleverantören i steg 2 och 3.

Svara med ett SAML-påstående

Identitetsleverantören slutför utbytet på baksidan genom att svara med ett SAML-påstående kopplat till ett SAML SOAP-meddelande:


  
  
  
    
      
       
      
      
      
      
         
      
      
        
         
        
        
        
        
          
          
        
          
          
          
            
              
            
              
            
          
        
      
    
  
 HTTP/1.1 200 OK Content-Type: text/xml Content-Length: nnnn  <SOAP-ENV:Envelope  xmlns:SOAP-ENV=  "http://schemas.xmlsoap.org/soap/envelope/"  >  <SOAP-ENV :Header/>  <SOAP-ENV:Body>  <samlp:Response  xmlns:samlp=  "urn:oasis:names:tc:SAML:1.0:protocol"  MajorVersion=  "1"  MinorVersion=  "1"  ResponseID=  "_P1YaA+Q /wSM/t/8E3R8rNhcpPTM="  InResponseTo=  "_192.168.16.51.1024506224022"  IssueInstant=  "2002-06-19T17:05:37.795Z"  >  <samlp:StatusSuc> <samlp:StatusSuc>  <samlp:StatusSuc>  <  samlp:StatusSuc  >  </samlp:Status>  <saml:Assertion  xmlns:saml=  "urn:oasis:names:tc:SAML:1.0:assertion"  MajorVersion=  "1"  MinorVersion=  "1"  AssertionID=  "buGxcG4gILg5NlocyLccDz6iXrUa"  : Issuer=  "https /idp.example.org/saml"  IssueInstant=  "2002-06-19T17:05:37.795Z"  >  <saml:Conditions  NotBefore=  "2002-06-19T17:00:37.795Z"  NotOnOrAfter=  "2002-17 :10:37.795Z"  />  <saml:AuthenticationStatement  AuthenticationMethod=  "urn:oasis:names:tc:SAML:1.0:am:password"  AuthenticationInstant=  "2002-06-19T17:05:17.706Z"  >  <ject >  <saml:NameIdentifier  Format=  "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"  >  [email protected]  </saml:NameIdentifier>  <saml:SubjectConfirmation>  <saml:ConfirmationMethod>  urn:oasis:names:tc:SAML:1.0:cm:artifact  </saml:ConfirmationMethod>  </saml:SubjectConfirmation>  </saml:Subject>  </saml:AuthenticationStatement>  </saml:Assertion>  </samlp:Response >  </SOAP-ENV:Body>  </SOAP-ENV:Envelope>

I det här fallet innehåller autentiseringssatsen en NameIdentifier som innehåller huvudmannens e-postadress.

Svara på rektors begäran

Assertion Consumer Service analyserar SAML Response- elementet, skapar en säkerhetskontext hos tjänsteleverantören och omdirigerar användaragenten till målresursen.

Se även

Hämtad från " https://en.wikipedia.org/w/index.php?title=SAML_1.1&oldid=1003976448 "