SAML 2.0

Język znaczników asercji zabezpieczeń
Skrót SAML
Status Opublikowany
Rok się rozpoczął Listopad 2003
Ostatnia wersja
Wersja 2.0 marzec 2005
Wersja podglądowa
Wersja 2.0 z erratą z maja 2019 r
Organizacja Organizacja ds. Rozwoju Standardów Informacji Strukturalnej (OASIS)
Komisja Komitet Techniczny Służb Bezpieczeństwa OASIS (SAML).
Strona internetowa Wiki o OASIS SAML

Security Assertion Markup Language 2.0 ( SAML 2.0 ) to wersja standardu SAML służąca do wymiany tożsamości uwierzytelniających i autoryzacyjnych pomiędzy domenami bezpieczeństwa . SAML 2.0 to protokół oparty na języku XML , który wykorzystuje tokeny bezpieczeństwa zawierające potwierdzenia do przekazywania informacji o zleceniodawcy (zwykle użytkowniku końcowym) pomiędzy organem SAML, zwanym dostawcą tożsamości , a konsumentem SAML, zwanym dostawcą usług . SAML 2.0 umożliwia internetowe jednokrotne logowanie w wielu domenach (SSO), co pomaga zmniejszyć obciążenie administracyjne związane z dystrybucją wielu tokenów uwierzytelniających do użytkownika.

SAML 2.0 został ratyfikowany jako standard OASIS w marcu 2005 roku, zastępując SAML 1.1 . Krytyczne aspekty SAML 2.0 są szczegółowo omówione w oficjalnych dokumentach SAMLCore, SAMLBind, SAMLProf i SAMLMeta.

W tworzenie SAML 2.0 zaangażowanych było około 30 osób z ponad 24 firm i organizacji. W szczególności, co zasługuje na szczególną uwagę, Liberty Alliance przekazało swoją specyfikację Identity Federation Framework (ID-FF) firmie OASIS, która stała się podstawą specyfikacji SAML 2.0. Zatem SAML 2.0 reprezentuje zbieżność SAML 1.1 , Liberty ID-FF 1.2 i Shibboleth 1.3 .

Twierdzenia SAML 2.0

Twierdzenie to pakiet informacji zawierający zero lub więcej stwierdzeń wydanych przez organ SAML. Asercje SAML są zwykle dokonywane na temat podmiotu reprezentowanego przez <Subject> . Specyfikacja SAML 2.0 definiuje trzy różne rodzaje stwierdzeń, które mogą być tworzone przez urząd SAML. Wszystkie instrukcje zdefiniowane w SAML są powiązane z tematem. Zdefiniowano trzy rodzaje stwierdzeń asercyjnych:

  • Oświadczenie uwierzytelniające: Podmiot potwierdzenia został uwierzytelniony w określony sposób w określonym czasie.
  • Instrukcja atrybutu: Podmiot potwierdzenia jest powiązany z dostarczonymi atrybutami.
  • Oświadczenie decyzji o autoryzacji: Żądanie umożliwienia podmiotowi potwierdzenia dostępu do określonego zasobu zostało przyjęte lub odrzucone.

Ważnym rodzajem asercji SAML jest tak zwana asercja „nośnika” używana w celu ułatwienia logowania jednokrotnego w przeglądarce internetowej. Oto przykład krótkotrwałego potwierdzenia okaziciela wydanego przez dostawcę tożsamości (https://idp.example.org/SAML2) dostawcy usług (https://sp.example.com/SAML2). Twierdzenie obejmuje zarówno potwierdzenie uwierzytelnienia <saml:AuthnStatement>, jak i potwierdzenie atrybutu <saml:AttributeStatement> , które prawdopodobnie wykorzystuje dostawca usług do podjęcia decyzji dotyczącej kontroli dostępu. Przedrostek saml: reprezentuje przestrzeń nazw asercji SAML V2.0.

Przykład SAML-a 


   
   
   
   
   
   
   
      <saml:Assertion  xmlns:saml=  "urn:oasis:names:tc:SAML:2.0:assertion"  xmlns:xs=  "http://www.w3.org/2001/XMLSchema"  ID=  "_d71a3a8e9fcc45c9e9d248ef7049393fc8f04e5f75"  Version=  " 2.0"  IssueInstant=  "2004-12-05T09:22:05Z"  >  <saml:Issuer>  https://idp.example.org/SAML2  </saml:Issuer>  <ds:Signature  xmlns:ds=  "http:/ /www.w3.org/2000/09/xmldsig#"  >  ...  </ds:Podpis> 
   
     
       
     
       
       
         
         
          <saml:Subject>  <saml:NameID  Format=  "urn:oasis:names:tc:SAML:2.0:nameid-format:transient"  >  3f7b3dcf-1674-4ecd-92c8-1544f346baf8  </saml:NameID>  <saml:SubjectConfirmation  Metoda=  "urn:oasis:names:tc:SAML:2.0:cm:bearer"  >  <saml:SubjectConfirmationData  InResponseTo=  "aaf23196-1773-2113-474a-fe114412ab72"  Odbiorca=  "https://sp.example.com/ SAML2/SSO/POST"  NotOnOrAfter=  "2004-12-05T09:27:05Z"  /> 
     
   
   
     
     
     
       
     
   
   
     
      </saml:SubjectConfirmation>  </saml:Subject>  <saml:Conditions  NotBefore=  "2004-12-05T09:17:05Z"  NotOnOrAfter=  "2004-12-05T09:27:05Z"  >  <saml:AudienceRestriction>  <saml :Audience>  https://sp.example.com/SAML2  </saml:Audience>  </saml:AudienceRestriction>  </saml:Conditions>  <saml:AuthnStatement  AuthnInstant=  "2004-12-05T09:22:00Z"  SessionIndex =  "b07b804c-7c29-ea16-7300-4f3d6f7928ac"  > 
     
       
     
   
   
     
       
       
       
        <saml:AuthnContext>  <saml:AuthnContextClassRef>  urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport <  /saml:AuthnContextClassRef>  </saml:AuthnContext>  </saml:AuthnStatement>  <saml:AttributeStatement>  <saml:Attribute  xmlns:x500=  "urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"  x500:Encoding=  "LDAP"  NameFormat=  "urn:oasis:names:tc:SAML:2.0:attrname -format:uri"  Nazwa=  "urna:oid:1.3.6.1.4.1.5923.1.1.1.1" 
       
       
         
       
         
     
   
  FriendlyName=  "eduPersonAffiliation"  >  <saml:AttributeValue  xsi:type=  "xs:string"  >  członek  </saml:AttributeValue>  <saml:AttributeValue  xsi:type=  "xs:string"  >  personel  </saml:AttributeValue>  </ saml:Attribute>  </saml:AttributeStatement>  </saml:Assertion>

Należy zauważyć, że w powyższym przykładzie element <saml:Assertion> zawiera następujące elementy potomne:

  • element <saml:Issuer> , który zawiera unikalny identyfikator dostawcy tożsamości
  • element <ds:Signature> , który zawiera podpis cyfrowy zachowujący integralność (nie pokazany) nad elementem <saml:Assertion>
  • element <saml:Subject> , który identyfikuje uwierzytelnionego głównego zobowiązanego (ale w tym przypadku tożsamość głównego zobowiązanego jest ukryta za nieprzezroczystym przejściowym identyfikatorem ze względu na prywatność)
  • element <saml:Conditions> , który podaje warunki, zgodnie z którymi stwierdzenie ma zostać uznane za ważne
  • element <saml:AuthnStatement> , który opisuje czynność uwierzytelniania u dostawcy tożsamości
  • element <saml:AttributeStatement> , który potwierdza wielowartościowy atrybut powiązany z uwierzytelnionym podmiotem głównym

Słowem, asercja koduje następujące informacje:

Twierdzenie („b07b804c-7c29-ea16-7300-4f3d6f7928ac”) zostało wydane o godzinie „2004-12-05T09:22:05Z” przez dostawcę tożsamości (https://idp.example.org/SAML2) w związku z tematem (3f7b3dcf -1674-4ecd-92c8-1544f346baf8) wyłącznie dla usługodawcy (https://sp.example.com/SAML2).

W szczególności oświadczenie uwierzytelniające stwierdza, co następuje:

Zleceniodawca zidentyfikowany w elemencie <saml:Subject> został uwierzytelniony w czasie „2004-12-05T09:22:00Z” za pomocą hasła przesłanego chronionym kanałem.

Podobnie instrukcja atrybutu stwierdza, że:

Zleceniodawca zidentyfikowany w elemencie <saml:Subject> ma w tej instytucji atrybuty „personel” i „członek”.

Protokoły SAML 2.0

W SAMLCore określono następujące protokoły:

Najważniejszy z tych protokołów — protokół żądania uwierzytelnienia — został szczegółowo omówiony poniżej.

Protokół żądania uwierzytelnienia

W przeglądarce internetowej SAML 1.1 profile SSO są inicjowane przez dostawcę tożsamości (IDP) , co oznacza, że ​​niechciany element <samlp:Response> jest przesyłany od dostawcy tożsamości do dostawcy usług (za pośrednictwem przeglądarki). (Przedrostek samlp: oznacza przestrzeń nazw protokołu SAML.)

Jednak w SAML 2.0 przepływ rozpoczyna się u dostawcy usług, który wysyła do dostawcy tożsamości wyraźne żądanie uwierzytelnienia. Powstały protokół żądania uwierzytelnienia jest znaczącą nową funkcją SAML 2.0.

Gdy mocodawca (lub podmiot działający w jego imieniu) chce uzyskać potwierdzenie zawierające oświadczenie uwierzytelniające, do dostawcy tożsamości przesyłany jest element <samlp:AuthnRequest> : 

  
    
    
    
    
    
    
    
    
     <samlp:AuthnRequest  xmlns:samlp=  "urn:oasis:names:tc:SAML:2.0:protocol"  xmlns:saml=  "urn:oasis:names:tc:SAML:2.0:assertion"  ID=  "aaf23196-1773-2113 -474a-fe114412ab72"  Wersja=  "2.0"  IssueInstant=  "2004-12-05T09:21:59Z"  AssertionConsumerServiceIndex=  "0"  AttributeConsumingServiceIndex=  "0"  >  <saml:Issuer>  https://sp.example.com/SAML2  </saml:Issuer>  <samlp:NameIDPolicy 
      
      
   AllowCreate=  "true"  Format=  "urn:oasis:names:tc:SAML:2.0:nameid-format:transient"  />  </samlp:AuthnRequest>

Powyższy element <samlp:AuthnRequest> , który w sposób dorozumiany żąda potwierdzenia zawierającego oświadczenie uwierzytelniające , został ewidentnie wydany przez usługodawcę (https://sp.example.com/SAML2), a następnie przedstawiony dostawcy tożsamości (za pośrednictwem przeglądarki ). Dostawca tożsamości uwierzytelnia zleceniodawcę (jeśli to konieczne) i wydaje odpowiedź uwierzytelniającą, która jest przesyłana z powrotem do dostawcy usług (ponownie za pośrednictwem przeglądarki).

Protokół rozwiązywania artefaktów

Komunikat SAML jest przesyłany z jednej jednostki do drugiej albo poprzez wartość , albo przez odniesienie . Odwołanie do komunikatu SAML nazywane jest artefaktem . Odbiorca artefaktu rozwiązuje odwołanie, wysyłając <samlp:ArtifactResolve> bezpośrednio do wystawcy artefaktu, który następnie odpowiada, przesyłając rzeczywisty komunikat, do którego odwołuje się artefakt.

Załóżmy na przykład, że dostawca tożsamości wysyła następujące żądanie <samlp:ArtifactResolve> bezpośrednio do dostawcy usług (za pośrednictwem kanału zwrotnego): 

  
    
    
    
    
    
    
    
    
       <samlp:ArtifactResolve  xmlns:samlp=  "urn:oasis:names:tc:SAML:2.0:protocol"  xmlns:saml=  "urn:oasis:names:tc:SAML:2.0:assertion"  ID=  "_cce4ee769ed970b501d680f697989d14"  Wersja=  " 2.0"  IssueInstant=  "2004-12-05T09:21:58Z"  >  <saml:Issuer>  https://idp.example.org/SAML2  </saml:Issuer>  <!-- wiadomość ArtifactResolve POWINNA być podpisana -- >  <ds:Signature  xmlns:ds=  "http://www.w3.org/2000/09/xmldsig#" 
    
   >  ...  </ds:Signature>  <samlp:Artifact>  AAQAAMh48/1oXIM+sDo7Dh2qMp1HM4IF5DaRNmDj6RdUmllwn9jJHyEgIi8=  </samlp:Artifact>  </samlp:ArtifactResolve>

W odpowiedzi dostawca usług zwraca element SAML, do którego odwołuje się załączony artefakt. Protokół ten stanowi podstawę wiązania artefaktów HTTP .

Powiązania SAML 2.0

Powiązania obsługiwane przez SAML 2.0 są opisane w specyfikacji Bindings (SAMLBind):

W przypadku logowania jednokrotnego w przeglądarce internetowej powszechnie używane jest powiązanie przekierowania HTTP i powiązanie HTTP POST. Na przykład dostawca usług może użyć przekierowania HTTP do wysłania żądania, podczas gdy dostawca tożsamości używa protokołu HTTP POST do przesłania odpowiedzi. Przykład ten ilustruje, że wybór wiązania dokonany przez jednostkę jest niezależny od wyboru wiązania dokonanego przez jej partnera.

Powiązanie przekierowania HTTP

Komunikaty protokołu SAML mogą być przenoszone bezpośrednio w ciągu zapytania URL żądania HTTP GET. Ponieważ długość adresów URL jest w praktyce ograniczona, powiązanie HTTP Redirect jest odpowiednie dla krótkich wiadomości, takich jak wiadomość <samlp:AuthnRequest> . Dłuższe wiadomości (np. zawierające podpisane lub zaszyfrowane potwierdzenia SAML, takie jak odpowiedzi SAML) są zwykle przesyłane za pośrednictwem innych powiązań, takich jak powiązanie HTTP POST .

Żądania lub odpowiedzi SAML przesyłane za pośrednictwem przekierowania HTTP mają odpowiednio parametr ciągu zapytania SAMLRequest lub SAMLResponse . Przed wysłaniem wiadomość jest deflowana (bez nagłówka i sumy kontrolnej), kodowana w formacie Base64 i kodowana w adresie URL, w tej kolejności. Po odebraniu proces jest odwracany w celu odzyskania oryginalnej wiadomości.

Na przykład, zakodowanie powyższego komunikatu <samlp:AuthnRequest> daje: 

https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=fZFfa8IwFMXfBb9DyXvaJtZ1BqsURRC2 Mabbw95ivc5Am3TJrXPffmmLY3%2FA15Pzuyf33On8XJXBCaxTRmeEhTEJQBdmr%2FRbRp63K3pL5rPhYOpk VdY ib%2FCon%2BC9AYfDQRB4WDvRvWWksVoY6ZQTWlbgBBZik9%2FfCR7GorYGTWFK8pu6DknnwKL%2FWEetlxmR8s BHbHJDWZqOKGdsRJM0kfQAjCUJ43KX8s78ctnIz%2Blp5xpYa4d So1fjOKGM03i8jSeCMzGevHa2%2FBK5MNo1F dgN2JMqPLmHc0b6WTmiVbsGoTf5qv66Zq2t60x0wXZ2RKydiCJXh3CWVV1CWJgqanfl0%2Bin8xutxYOvZL18NK UqPlvZR5el%2BVhYkAg ZQdsA6fWVsZXE63W2itrTQ2cVaKV2CjSSqL1v9P%2FAXv4C

Powyższa wiadomość (sformatowana pod kątem czytelności) może zostać podpisana dla dodatkowego bezpieczeństwa. W praktyce wszystkie dane zawarte w <samlp:AuthnRequest> , takie jak Emitent zawierający identyfikator SP ID oraz NameIDPolicy , zostały wcześniej uzgodnione pomiędzy IdP a SP (poprzez ręczną wymianę informacji lub metadane SAML ). W takim przypadku podpisanie wniosku nie stanowi ograniczenia bezpieczeństwa. Jeśli <samlp:AuthnRequest> zawiera informacje nieznane wcześniej dostawcy tożsamości, takie jak adres URL usługi Assertion Consumer Service, ze względów bezpieczeństwa zalecane jest podpisanie żądania.

Powiązanie HTTP POST

W poniższym przykładzie zarówno dostawca usług, jak i dostawca tożsamości używają powiązania HTTP POST. Początkowo usługodawca odpowiada na żądanie agenta użytkownika dokumentem zawierającym formularz XHTML: 

     
         <  metoda  formularza  =  akcja  „post”  =  „https://idp.example.org/SAML2/SSO/POST”  ...  >  <  typ  danych wejściowych  =  „ukryta”  nazwa  =  „SAMLRequest”  wartość  =  „''żądanie'' "  />  ... inny parametr wejściowy....  </  form  >

Wartość parametru SAMLRequest to kodowanie base64 elementu <samlp:AuthnRequest> , który jest przesyłany do dostawcy tożsamości za pośrednictwem przeglądarki. Usługa SSO u dostawcy tożsamości sprawdza żądanie i odpowiada dokumentem zawierającym inny formularz XHTML: 

     
         <  metoda  formularza  =  akcja  „post”  =  „https://sp.example.com/SAML2/SSO/POST”  ...  >  <  typ  danych wejściowych  =  „ukryta”  nazwa  =  wartość  „SAMLResponse”  =  „''odpowiedź'' "  />  ...  </  formularz  >

Wartość parametru SAMLResponse to kodowanie base64 elementu <samlp:Response> , które również jest przesyłane do usługodawcy za pośrednictwem przeglądarki.

Aby zautomatyzować przesyłanie formularza, w dowolnym miejscu strony XHTML może pojawić się następujący wiersz kodu JavaScript:

       0  okno  .  onload  =  funkcja  ()  {  dokument  .  formy  [  ].  przesłać  ();  }

Zakłada to oczywiście, że pierwszy element formularza na stronie zawiera powyższy SAMLResponse zawierający element formularza ( forms[0] ).

Powiązanie artefaktów HTTP

Powiązanie artefaktów HTTP korzysta z protokołu rozpoznawania artefaktów i powiązania SAML SOAP (przez protokół HTTP) w celu rozpoznania komunikatu SAML przez odwołanie. Rozważ następujący konkretny przykład. Załóżmy, że dostawca usług chce wysłać <samlp:AuthnRequest> do dostawcy tożsamości. Początkowo dostawca usług przesyła artefakt do dostawcy tożsamości za pośrednictwem przekierowania HTTP: 

 https://idp.example.org/SAML2/SSO/Artifact?SAMLart=  artefakt

Następnie dostawca tożsamości wysyła żądanie <samlp:ArtifactResolve> (takie jak pokazane wcześniej ArtifactResolveRequest ) bezpośrednio do dostawcy usług za pośrednictwem kanału zwrotnego. Na koniec usługodawca zwraca <samlp:ArtifactResponse> zawierający przywoływany komunikat <samlp:AuthnRequest> : 

  
    
    
    
    
    
    
    
      
     <samlp:ArtifactResponse  xmlns:samlp=  "urn:oasis:names:tc:SAML:2.0:protocol"  ID=  "_d84a49e5958803dedcff4c984c2b0d95"  InResponseTo=  "_cce4ee769ed970b501d680f697989d14"  Wersja=  "2.0"  Problem Natychmiastowe=  "2004-12-05T09:21:59Z "  >  <!-- Wiadomość ArtifactResponse NALEŻY podpisać -->  <ds:Signature  xmlns:ds=  "http://www.w3.org/2000/09/xmldsig#"  >  ...  </ds:Signature >  <samlp:Status> 
      
        
    
    
      
      
      
      
      
      
       <samlp:StatusCode  Value=  "urn:oasis:names:tc:SAML:2.0:status:Success"  />  </samlp:Status>  <samlp:AuthnRequest  xmlns:samlp=  "urn:oasis:names:tc:SAML: 2.0:protocol"  xmlns:saml=  "urn:oasis:names:tc:SAML:2.0:assertion"  ID=  "_306f8ec5b618f361c70b6ffb1480eade"  Wersja=  "2.0"  IssueInstant=  "2004-12-05T09:21:59Z"  Destination=  "https ://idp.example.org/SAML2/SSO/Artifact”  ProtocolBinding= 
      
      
      
        
        
    
   "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"  AssertionConsumerServiceURL=  "https://sp.example.com/SAML2/SSO/Artifact"  >  <saml:Issuer>  https://sp. example.com/SAML2  </saml:Issuer>  <samlp:NameIDPolicyAllowCreate  =  "false"  Format=  "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"  />  </samlp:AuthnRequest>  < /samlp:Odpowiedź na artefakt>

Oczywiście przepływ może również przebiegać w drugą stronę, to znaczy dostawca tożsamości może wygenerować artefakt, co w rzeczywistości zdarza się częściej. Zobacz na przykład przykład profilu „ podwójny artefakt ” w dalszej części tego tematu.

Format artefaktu

Ogólnie artefakt SAML 2.0 definiuje się w następujący sposób (SAMLBind): 

SAML_artifact := B64 (TypeCode EndpointIndex RemainingArtifact) TypeCode := Bajt1Byte2 EndpointIndex := Bajt1Byte2

Zatem artefakt SAML 2.0 składa się z trzech komponentów: dwubajtowego TypeCode , dwubajtowego EndpointIndex i dowolnej sekwencji bajtów zwanej RemainingArtifact . Te trzy informacje są łączone i kodowane w formacie Base64 w celu uzyskania kompletnego artefaktu.

TypeCode jednoznacznie identyfikuje format artefaktu . SAML 2.0 predefiniuje tylko jeden taki artefakt, typu 0x0004. EndpointIndex jest odniesieniem do konkretnego punktu końcowego rozpoznawania artefaktów zarządzanego przez wystawcę artefaktów (którym może być dostawca tożsamości lub dostawca usług, jak wspomniano wcześniej) . RemainingArtifact , który jest określony przez definicję typu, jest „mięsem” artefaktu.

Format artefaktu typu 0x0004 jest dalej zdefiniowany w następujący sposób: 

TypeCode := 0x0004 RemainingArtifact := SourceId MessageHandle SourceId := 20-bajtowa_sekwencja MessageHandle := 20-bajtowa_sekwencja

Zatem artefakt typu 0x0004 ma rozmiar 44 bajty (niekodowany). SourceId to dowolna sekwencja bajtów, chociaż w praktyce SourceId to skrót SHA- 1 identyfikatora podmiotu wystawcy. MessageHandle to losowa sekwencja bajtów odwołująca się do komunikatu SAML, który wystawca artefaktu chce wygenerować na żądanie .

Rozważmy na przykład ten artefakt typu 0x0004 zakodowany w formacie szesnastkowym:

00040000c878f3fd685c833eb03a3b0e1daa329d47338205e436913660e3e917549a59709fd8c91f2120222f

Jeśli przyjrzysz się uważnie, zobaczysz TypeCode (0x0004) i EndpointIndex (0x0000) z przodu artefaktu. Następne 20 bajtów to skrót SHA-1 identyfikatora podmiotu wystawcy (https://idp.example.org/SAML2), po którym następuje 20 losowych bajtów. Kodowanie base64 tych 44 bajtów widać w ArtifactResolveRequest .

Profile SAML 2.0

W SAML 2.0, podobnie jak w SAML 1.1, głównym przypadkiem użycia jest nadal logowanie jednokrotne w przeglądarce internetowej, ale zakres SAML 2.0 jest szerszy niż w poprzednich wersjach SAML, jak sugeruje poniższa wyczerpująca lista profili:

Chociaż liczba obsługiwanych profili jest dość duża, specyfikacja Profiles (SAMLProf) jest uproszczona, ponieważ wiążące aspekty każdego profilu zostały uwzględnione w osobnej specyfikacji Bindings (SAMLBind).

Profil SSO przeglądarki internetowej

SAML 2.0 określa profil SSO przeglądarki internetowej obejmujący dostawcę tożsamości (IdP), dostawcę usług (SP) i podmiot zabezpieczeń posiadający agenta użytkownika HTTP. Dostawca usług ma do wyboru cztery powiązania, natomiast dostawca tożsamości ma trzy, co prowadzi do dwunastu możliwych scenariuszy wdrożenia. Poniżej przedstawiamy trzy z tych scenariuszy wdrażania.

Żądanie przekierowania SP; Odpowiedź dostawcy tożsamości POST

To jeden z najczęstszych scenariuszy. Dostawca usług wysyła żądanie SAML do usługi SSO dostawcy tożsamości za pomocą powiązania przekierowania HTTP. Dostawca tożsamości zwraca odpowiedź SAML do usługi konsumenckiej potwierdzenia SP przy użyciu powiązania HTTP-POST.

Przeglądarka internetowa SAML 2.0 SSO (powiązanie przekierowania SP/odpowiedź POST dostawcy tożsamości)

Przepływ komunikatów rozpoczyna się od żądania zabezpieczonego zasobu u usługodawcy.

1. Poproś o zasób docelowy u SP

Zleceniodawca (za pośrednictwem klienta użytkownika HTTP) żąda zasobu docelowego u dostawcy usług:

https://sp.example.com/myresource

Dostawca usług przeprowadza kontrolę bezpieczeństwa w imieniu zasobu docelowego. Jeśli u usługodawcy istnieje już prawidłowy kontekst zabezpieczeń, pomiń kroki 2–7.

Dostawca usług może zastosować dowolny mechanizm w celu wykrycia dostawcy tożsamości, który będzie używany, np. zapytać użytkownika, skorzystać ze wstępnie skonfigurowanego dostawcy tożsamości itp.

2. Przekieruj do usługi IdP SSO

Dostawca usługi generuje odpowiedni SAMLRequest (i RelayState, jeśli istnieje), a następnie przekierowuje przeglądarkę do usługi IdP SSO przy użyciu standardowego przekierowania HTTP 302 . 


 przekierowania 302  : https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token

Token RelayState stanowi nieprzejrzyste odniesienie do informacji o stanie przechowywanych u dostawcy usług. Wartość SAMLRequest to deflowana, zakodowana w formacie Base64 i URL wartość elementu <samlp:AuthnRequest> : 

  
    
    
    
    
    
    
    
    
      
       <samlp:AuthnRequest  xmlns:samlp=  "urn:oasis:names:tc:SAML:2.0:protocol"  xmlns:saml=  "urn:oasis:names:tc:SAML:2.0:assertion"  ID=  "identyfikator_1"  Wersja=  " 2.0"  IssueInstant=  "2004-12-05T09:21:59Z"  AssertionConsumerServiceIndex=  "0"  >  <saml:Issuer>  https://sp.example.com/SAML2  </saml:Issuer>  <samlp:NameIDPolicyAllowCreate  =  " prawda”  Format= 
   "urn:oasis:names:tc:SAML:2.0:nameid-format:transient"  />  </samlp:AuthnRequest>

Żądanie SAMLRequest można podpisać przy użyciu klucza podpisującego SP. Zwykle jednak nie jest to konieczne.

3. Poproś o usługę SSO u dostawcy tożsamości

Agent użytkownika wysyła żądanie GET do usługi SSO u dostawcy tożsamości:

  
  GET  /SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token  HTTP  /  1.1  Host  :  idp.example.org

gdzie wartości parametrów SAMLRequest i RelayState są takie same, jak te podane w przekierowaniu. Usługa SSO u dostawcy tożsamości przetwarza <samlp:AuthnRequest> (poprzez dekodowanie adresu URL, dekodowanie base64 i powiększanie żądania, w tej kolejności) i przeprowadza kontrolę bezpieczeństwa. Jeśli użytkownik nie ma prawidłowego kontekstu zabezpieczeń, dostawca tożsamości identyfikuje użytkownika za pomocą dowolnego mechanizmu (szczegóły pominięto).

4. Odpowiedz za pomocą formularza XHTML

Usługa SSO zatwierdza żądanie i odpowiada dokumentem zawierającym formularz XHTML:

     
 <  metoda  formularza  =  akcja  „post”  =  „https://sp.example.com/SAML2/SSO/POST”  ...  >          <  typ  danych wejściowych  =  „ukryta”  nazwa  =  wartość  „SAMLResponse”  =  „odpowiedź”  /> 
         <  typ  wejścia  =  „ukryty”  nazwa  =  „RelayState”  wartość  =  „token”  /> 
   
   ...  <  typ  wejścia  =  „prześlij”  wartość  =  „Prześlij”  />  </  formularz  >

Wartość parametru RelayState została zachowana z kroku 3. Wartość parametru SAMLResponse to kodowanie base64 następującego elementu <samlp:Response> : 

  
    
    
    
    
    
    
    
    
    
       <samlp:Response  xmlns:samlp=  "urn:oasis:names:tc:SAML:2.0:protocol"  xmlns:saml=  "urn:oasis:names:tc:SAML:2.0:assertion"  ID=  "identyfikator_2"  InResponseTo=  " identyfikator_1"  Wersja=  "2.0"  IssueInstant=  "2004-12-05T09:22:05Z"  Destination=  "https://sp.example.com/SAML2/SSO/POST"  >  <saml:Issuer>  https://idp .example.org/SAML2  </saml:Issuer>  <samlp:Status>  <samlp:StatusCode 
        
    
    
      
      
      
      
      
      
      
         Wartość=  "urn:oasis:names:tc:SAML:2.0:status:Success"  />  </samlp:Status>  <saml:Assertion  xmlns:saml=  "urn:oasis:names:tc:SAML:2.0:assertion"  ID=  "identifier_3"  Wersja=  "2.0"  IssueInstant=  "2004-12-05T09:22:05Z"  >  <saml:Issuer>  https://idp.example.org/SAML2  </saml:Issuer>  <!-- wysłane potwierdzenie MUSI być podpisane -->  <ds:Signature  xmlns:ds= 
      
        
          
        
          
          
            
             "http://www.w3.org/2000/09/xmldsig#"  >  ...  </ds:Signature>  <saml:Subject>  <saml:NameID  Format=  "urn:oasis:names:tc:SAML: 2.0:nameid-format:transient"  >  3f7b3dcf-1674-4ecd-92c8-1544f346baf8  </saml:NameID>  <saml:SubjectConfirmation  Method=  "urn:oasis:names:tc:SAML:2.0:cm:bearer"  >  <saml :SubjectConfirmationData  InResponseTo=  "identyfikator_1"  Odbiorca= 
            
        
      
      
        
        
        
          
        
      
      
         "https://sp.example.com/SAML2/SSO/POST"  NotOnOrAfter=  "2004-12-05T09:27:05Z"  />  </saml:SubjectConfirmation>  </saml:Subject>  <saml:Conditions  NotBefore=  "2004-12-05T09:17:05Z"  NotOnOrAfter=  "2004-12-05T09:27:05Z"  >  <saml:AudienceRestriction>  <saml:Audience>  https://sp.example.com/SAML2  </saml: Odbiorcy>  </saml:AudienceRestriction>  </saml:Conditions>  <saml:AuthnStatement  AuthnInstant= 
        
        
          
        
      
    
   "2004-12-05T09:22:00Z"  SessionIndex=  "identifier_3"  >  <saml:AuthnContext>  <saml:AuthnContextClassRef>  urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport  </saml:AuthnContextClassRef>  </saml:AuthnContext>  </saml:AuthnStatement>  </saml:Assertion>  </samlp:Response>

5. Złóż wniosek o obsługę konsumencką w SP

Agent użytkownika wysyła żądanie POST do działu obsługi klienta Assertion u usługodawcy:

  
 
 
 
 
 POST  /SAML2/SSO/POST  HTTP  /  1.1  Host  :  sp.example.com  Typ zawartości  :  application/x-www-form-urlencoded  Długość treści  :  nnn  SAMLResponse=response&RelayState=token

gdzie wartości parametrów SAMLResponse i RelayState są pobierane z formularza XHTML w kroku 4.

6. Przekieruj do zasobu docelowego

Usługa konsumenta asercji przetwarza odpowiedź, tworzy kontekst bezpieczeństwa u dostawcy usług i przekierowuje agenta użytkownika do zasobu docelowego.

7. Poproś ponownie o zasób docelowy u SP

Agent użytkownika żąda zasobu docelowego od dostawcy usług (ponownie):

https://sp.example.com/myresource

8. Odpowiedz, podając żądany zasób

Ponieważ istnieje kontekst bezpieczeństwa, dostawca usług zwraca zasób agentowi użytkownika.

Żądanie SP POST; Odpowiedź dostawcy tożsamości POST

Jest to stosunkowo proste wdrożenie profilu SSO przeglądarki internetowej SAML 2.0 (SAMLProf), w którym zarówno dostawca usług (SP), jak i dostawca tożsamości (IdP) korzystają z powiązania HTTP POST.

Przeglądarka internetowa SAML 2.0 Logowanie jednokrotne (POST)

Przepływ komunikatów rozpoczyna się od żądania zabezpieczonego zasobu w SP.

1. Poproś o zasób docelowy u SP

Zleceniodawca (za pośrednictwem klienta użytkownika HTTP) żąda zasobu docelowego u dostawcy usług:

https://sp.example.com/myresource

Dostawca usług przeprowadza kontrolę bezpieczeństwa w imieniu zasobu docelowego. Jeśli u usługodawcy istnieje już prawidłowy kontekst zabezpieczeń, pomiń kroki 2–7.

2. Odpowiedz za pomocą formularza XHTML

Usługodawca odpowiada dokumentem zawierającym formularz XHTML:

     
 <  metoda  formularza  =  akcja  „post”  =  „https://idp.example.org/SAML2/SSO/POST”  ...  >          <  typ  danych wejściowych  =  „ukryta”  nazwa  =  „SAMLRequest”  wartość  =  „żądanie”  /> 
         <  typ  wejścia  =  „ukryty”  nazwa  =  „RelayState”  wartość  =  „token”  /> 
   
   ...  <  typ  wejścia  =  „prześlij”  wartość  =  „Prześlij”  />  </  formularz  >

Token RelayState stanowi nieprzejrzyste odniesienie do informacji o stanie przechowywanych u dostawcy usług. Wartością SAMLRequest jest kodowanie base64 następującego elementu <samlp:AuthnRequest> : 

  
    
    
    
    
    
    
    
    
      
       <samlp:AuthnRequest  xmlns:samlp=  "urn:oasis:names:tc:SAML:2.0:protocol"  xmlns:saml=  "urn:oasis:names:tc:SAML:2.0:assertion"  ID=  "identyfikator_1"  Wersja=  " 2.0"  IssueInstant=  "2004-12-05T09:21:59Z"  AssertionConsumerServiceIndex=  "0"  >  <saml:Issuer>  https://sp.example.com/SAML2  </saml:Issuer>  <samlp:NameIDPolicyAllowCreate  =  " prawda”  Format= 
   "urn:oasis:names:tc:SAML:2.0:nameid-format:transient"  />  </samlp:AuthnRequest>

Zanim element <samlp:AuthnRequest> zostanie wstawiony do formularza XHTML, jest on najpierw kodowany w standardzie Base64.

3. Poproś o usługę SSO u dostawcy tożsamości

Agent użytkownika wysyła żądanie POST do usługi SSO u dostawcy tożsamości:

  
 
 
 

 POST  /SAML2/SSO/POST  Host  HTTP  /  1.1  :  idp.example.org  Typ zawartości  :  application/x-www-form-urlencoded  Długość treści  :  nnn  SAMLRequest=request&RelayState=token

gdzie wartości parametrów SAMLRequest i RelayState są pobierane z formularza XHTML w kroku 2. Usługa SSO przetwarza element <samlp:AuthnRequest> (poprzez dekodowanie adresu URL, dekodowanie base64 i powiększanie żądania, w tej kolejności) i wykonuje kontrolę bezpieczeństwa. Jeśli użytkownik nie ma prawidłowego kontekstu zabezpieczeń, dostawca tożsamości identyfikuje użytkownika (szczegóły pominięto).

4. Odpowiedz za pomocą formularza XHTML

Usługa SSO zatwierdza żądanie i odpowiada dokumentem zawierającym formularz XHTML:

     
 <  metoda  formularza  =  akcja  „post”  =  „https://sp.example.com/SAML2/SSO/POST”  ...  >          <  typ  danych wejściowych  =  „ukryta”  nazwa  =  wartość  „SAMLResponse”  =  „odpowiedź”  /> 
         <  typ  wejścia  =  „ukryty”  nazwa  =  „RelayState”  wartość  =  „token”  /> 
   
   ...  <  typ  wejścia  =  „prześlij”  wartość  =  „Prześlij”  />  </  formularz  >

Wartość parametru RelayState została zachowana z kroku 3. Wartość parametru SAMLResponse to kodowanie base64 następującego elementu <samlp:Response> : 

  
    
    
    
    
    
    
    
    
    
       <samlp:Response  xmlns:samlp=  "urn:oasis:names:tc:SAML:2.0:protocol"  xmlns:saml=  "urn:oasis:names:tc:SAML:2.0:assertion"  ID=  "identyfikator_2"  InResponseTo=  " identyfikator_1"  Wersja=  "2.0"  IssueInstant=  "2004-12-05T09:22:05Z"  Destination=  "https://sp.example.com/SAML2/SSO/POST"  >  <saml:Issuer>  https://idp .example.org/SAML2  </saml:Issuer>  <samlp:Status>  <samlp:StatusCode 
        
    
    
      
      
      
      
      
      
      
         Wartość=  "urn:oasis:names:tc:SAML:2.0:status:Success"  />  </samlp:Status>  <saml:Assertion  xmlns:saml=  "urn:oasis:names:tc:SAML:2.0:assertion"  ID=  "identifier_3"  Wersja=  "2.0"  IssueInstant=  "2004-12-05T09:22:05Z"  >  <saml:Issuer>  https://idp.example.org/SAML2  </saml:Issuer>  <!-- wysłane potwierdzenie MUSI być podpisane -->  <ds:Signature  xmlns:ds= 
      
        
          
        
          
          
            
             "http://www.w3.org/2000/09/xmldsig#"  >  ...  </ds:Signature>  <saml:Subject>  <saml:NameID  Format=  "urn:oasis:names:tc:SAML: 2.0:nameid-format:transient"  >  3f7b3dcf-1674-4ecd-92c8-1544f346baf8  </saml:NameID>  <saml:SubjectConfirmation  Method=  "urn:oasis:names:tc:SAML:2.0:cm:bearer"  >  <saml :SubjectConfirmationData  InResponseTo=  "identyfikator_1"  Odbiorca= 
            
        
      
      
        
        
        
          
        
      
      
         "https://sp.example.com/SAML2/SSO/POST"  NotOnOrAfter=  "2004-12-05T09:27:05Z"  />  </saml:SubjectConfirmation>  </saml:Subject>  <saml:Conditions  NotBefore=  "2004-12-05T09:17:05Z"  NotOnOrAfter=  "2004-12-05T09:27:05Z"  >  <saml:AudienceRestriction>  <saml:Audience>  https://sp.example.com/SAML2  </saml: Odbiorcy>  </saml:AudienceRestriction>  </saml:Conditions>  <saml:AuthnStatement  AuthnInstant= 
        
        
          
        
      
    
   "2004-12-05T09:22:00Z"  SessionIndex=  "identifier_3"  >  <saml:AuthnContext>  <saml:AuthnContextClassRef>  urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport  </saml:AuthnContextClassRef>  </saml:AuthnContext>  </saml:AuthnStatement>  </saml:Assertion>  </samlp:Response>

5. Złóż wniosek o obsługę konsumencką w SP

Agent użytkownika wysyła żądanie POST do usługi konsumenckiej potwierdzenia u usługodawcy:

  
 
 
 
 
 POST  /SAML2/SSO/POST  HTTP  /  1.1  Host  :  sp.example.com  Typ zawartości  :  application/x-www-form-urlencoded  Długość treści  :  nnn  SAMLResponse=response&RelayState=token

gdzie wartości parametrów SAMLResponse i RelayState są pobierane z formularza XHTML w kroku 4.

6. Przekieruj do zasobu docelowego

Usługa konsumenta asercji przetwarza odpowiedź, tworzy kontekst bezpieczeństwa u dostawcy usług i przekierowuje agenta użytkownika do zasobu docelowego.

7. Poproś ponownie o zasób docelowy u SP

Agent użytkownika żąda zasobu docelowego od dostawcy usług (ponownie):

https://sp.example.com/myresource

8. Odpowiedz, podając żądany zasób

Ponieważ istnieje kontekst bezpieczeństwa, dostawca usług zwraca zasób agentowi użytkownika.

Artefakt przekierowania SP; Artefakt przekierowania dostawcy tożsamości

Jest to złożone wdrożenie profilu SSO przeglądarki internetowej SAML 2.0 (SAMLProf), w którym zarówno dostawca usług (SP), jak i dostawca tożsamości (IdP) korzystają z powiązania artefaktu HTTP. Obydwa artefakty są dostarczane do odpowiednich punktów końcowych za pośrednictwem protokołu HTTP GET.

Przeglądarka internetowa SAML 2.0 Logowanie jednokrotne (artefakt)

Przepływ komunikatów rozpoczyna się od żądania zabezpieczonego zasobu w SP:

1. Poproś o zasób docelowy u SP

Zleceniodawca (za pośrednictwem klienta użytkownika HTTP) żąda zasobu docelowego u dostawcy usług:

https://sp.example.com/myresource

Dostawca usług przeprowadza kontrolę bezpieczeństwa w imieniu zasobu docelowego. Jeśli u usługodawcy istnieje już prawidłowy kontekst zabezpieczeń, pomiń kroki 2–11.

2. Przekieruj do usługi pojedynczego logowania (SSO) u dostawcy tożsamości

Dostawca usług przekierowuje agenta użytkownika do usługi pojedynczego logowania (SSO) u dostawcy tożsamości. Do adresu URL przekierowania dołączane są parametry RelayState i SAMLart .

3. Poproś o usługę SSO u dostawcy tożsamości

Agent użytkownika żąda usługi SSO u dostawcy tożsamości:

 https://idp.example.org/SAML2/SSO/Artifact?SAMLart=  artifact_1  &RelayState=  token

gdzie token to nieprzejrzyste odniesienie do informacji o stanie przechowywanych u dostawcy usług, a artefakt_1 to artefakt SAML, oba wygenerowane w kroku 2.

4. Poproś o usługę rozpoznawania artefaktów w SP

Usługa SSO usuwa referencję do artefaktu, wysyłając element <samlp:ArtifactResolve> powiązany z komunikatem SAML SOAP do usługi rozpoznawania artefaktów u dostawcy usługi: 

  
    
    
    
    
    
    
    
    
     <samlp:ArtifactResolve  xmlns:samlp=  "urn:oasis:names:tc:SAML:2.0:protocol"  xmlns:saml=  "urn:oasis:names:tc:SAML:2.0:assertion"  ID=  "identyfikator_1"  Wersja=  " 2.0"  IssueInstant=  "2004-12-05T09:21:58Z"  Destination=  "https://sp.example.com/SAML2/ArtifactResolution"  >  <saml:Issuer>  https://idp.example.org/SAML2  < /saml:Issuer>  <!-- wiadomość ArtifactResolve MUSI być podpisana -->  <ds:Signature 
      
    
   xmlns:ds=  "http://www.w3.org/2000/09/xmldsig#"  >  ...  </ds:Signature>  <samlp:Artifact>  ''artifact_1''  </samlp:Artifact>  </ samlp:Rozwiązywanie artefaktów>

gdzie wartością elementu <samlp:Artifact> jest artefakt SAML przesłany w kroku 3.

5. Odpowiedz za pomocą żądania SAML AuthnRequest

Usługa rozpoznawania artefaktów u dostawcy usługi zwraca element <samlp:ArtifactResponse> (zawierający element <samlp:AuthnRequest> ) powiązany z komunikatem SAML SOAP do usługi SSO u dostawcy tożsamości: 

  
    
    
    
    
    
    
    
      
    
      
         <samlp:ArtifactResponse  xmlns:samlp=  "urn:oasis:names:tc:SAML:2.0:protocol"  ID=  "identyfikator_2"  InResponseTo=  "identyfikator_1"  Wersja=  "2.0"  IssueInstant=  "2004-12-05T09:21:59Z "  >  <!-- Wiadomość ArtifactResponse NALEŻY podpisać -->  <ds:Signature  xmlns:ds=  "http://www.w3.org/2000/09/xmldsig#"  >  ...  </ds:Signature >  <samlp:Status>  <samlp:StatusCode  Value= 
    
    
      
      
      
      
      
      
       "urn:oasis:names:tc:SAML:2.0:status:Success"  /> <  /samlp:Status>  <samlp:AuthnRequest  xmlns:samlp=  "urn:oasis:names:tc:SAML:2.0:protocol"  xmlns: saml=  "urn:oasis:names:tc:SAML:2.0:assertion"  ID=  "identyfikator_3"  Wersja=  "2.0"  IssueInstant=  "2004-12-05T09:21:59Z"  Destination=  "https://idp.example .org/SAML2/SSO/Artifact"  ProtocolBinding=  "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" 
      
      
      
        
        
    
   AssertionConsumerServiceURL=  "https://sp.example.com/SAML2/SSO/Artifact"  >  <saml:Issuer>  https://sp.example.com/SAML2  </saml:Issuer>  <samlp:NameIDPolicyAllowCreate  =  "false "  Format=  "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"  />  </samlp:AuthnRequest>  </samlp:ArtifactResponse>

Usługa SSO przetwarza element <samlp:AuthnRequest> i przeprowadza kontrolę bezpieczeństwa. Jeśli użytkownik nie ma prawidłowego kontekstu zabezpieczeń, dostawca tożsamości identyfikuje użytkownika (szczegóły pominięto).

6. Przekieruj do Obsługi Konsumenckiej Asercji

Usługa SSO u dostawcy tożsamości przekierowuje agenta użytkownika do usługi konsumenta potwierdzenia u dostawcy usług. Poprzedni RelayState i nowy parametr SAMLart są dołączane do adresu URL przekierowania.

7. Złóż wniosek o obsługę konsumencką w SP

Agent użytkownika żąda świadczenia usługi konsumenckiej u usługodawcy:

 https://sp.example.com/SAML2/SSO/Artifact?SAMLart=  artifact_2  &RelayState=  token

gdzie token to wartość tokena z kroku 3, a artefakt_2 to artefakt SAML wystawiony w kroku 6.

8. Poproś o usługę rozpoznawania artefaktów u dostawcy tożsamości

Usługa konsumenta asercji odwołuje się do artefaktu, wysyłając element <samlp:ArtifactResolve> powiązany z komunikatem SAML SOAP do usługi rozpoznawania artefaktów u dostawcy tożsamości: 

  
    
    
    
    
    
    
    
    
     <samlp:ArtifactResolve  xmlns:samlp=  "urn:oasis:names:tc:SAML:2.0:protocol"  xmlns:saml=  "urn:oasis:names:tc:SAML:2.0:assertion"  ID=  "identyfikator_4"  Wersja=  " 2.0"  IssueInstant=  "2004-12-05T09:22:04Z"  Destination=  "https://idp.example.org/SAML2/ArtifactResolution"  >  <saml:Issuer>  https://sp.example.com/SAML2  < /saml:Issuer>  <!-- wiadomość ArtifactResolve MUSI być podpisana -->  <ds:Signature 
      
    
   xmlns:ds=  "http://www.w3.org/2000/09/xmldsig#"  >  ...  </ds:Signature>  <samlp:Artifact>  ''artifact_2''  </samlp:Artifact>  </ samlp:Rozwiązywanie artefaktów>

gdzie wartością elementu <samlp:Artifact> jest artefakt SAML przesłany w kroku 7.

9. Odpowiedz, używając asercji SAML

Usługa rozpoznawania artefaktów u dostawcy tożsamości zwraca element <samlp:ArtifactResponse> (zawierający element <samlp:Response> ) powiązany z komunikatem SAML SOAP do usługi konsumenckiej asercji u dostawcy usług: 

  
    
    
    
    
    
    
    
      
    
      
         <samlp:ArtifactResponse  xmlns:samlp=  "urn:oasis:names:tc:SAML:2.0:protocol"  ID=  "identyfikator_5"  InResponseTo=  "identyfikator_4"  Wersja=  "2.0"  IssueInstant=  "2004-12-05T09:22:05Z "  >  <!-- Wiadomość ArtifactResponse NALEŻY podpisać -->  <ds:Signature  xmlns:ds=  "http://www.w3.org/2000/09/xmldsig#"  >  ...  </ds:Signature >  <samlp:Status>  <samlp:StatusCode  Value= 
    
    
      
      
      
      
      
      
      
       "urn:oasis:names:tc:SAML:2.0:status:Success"  />  </samlp:Status>  <samlp:Response  xmlns:samlp=  "urn:oasis:names:tc:SAML:2.0:protocol"  xmlns: saml=  "urn:oasis:names:tc:SAML:2.0:assertion"  ID=  "identyfikator_6"  InResponseTo=  "identyfikator_3"  Wersja=  "2.0"  IssueInstant=  "2004-12-05T09:22:05Z"  Destination=  "https: //sp.example.com/SAML2/SSO/Artifact"  >  <saml:Issuer> 
      
        
      
        
          
      
      
        
        
        
         https://idp.example.org/SAML2  </saml:Issuer>  <ds:Signature  xmlns:ds=  "http://www.w3.org/2000/09/xmldsig#"  >  ...  </ds :Signature>  <samlp:Status>  <samlp:StatusCode  Value=  "urn:oasis:names:tc:SAML:2.0:status:Success"  />  </samlp:Status>  <saml:Assertion  xmlns:saml=  "urn: oasis:names:tc:SAML:2.0:assertion"  ID=  "identyfikator_7"  Wersja=  "2.0"  IssueInstant= 
        
        
        
          
            
          
            
            
               "2004-12-05T09:22:05Z"  >  <saml:Issuer>  https://idp.example.org/SAML2  </saml:Issuer>  <!-- wymagany jest element tematu -->  <saml:Subject >  <saml:NameID  Format=  "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"  >  [email protected]  </saml:NameID>  <saml:SubjectConfirmation  Method=  "urn:oasis :names:tc:SAML:2.0:cm:bearer"  >  <saml:SubjectConfirmationData  InResponseTo= 
              
              
          
        
        
          
          
          
            
           "identifier_3"  Recipient=  "https://sp.example.com/SAML2/SSO/Artifact"  NotOnOrAfter=  "2004-12-05T09:27:05Z"  />  </saml:SubjectConfirmation>  </saml:Subject>  < saml:Conditions  NotBefore=  "2004-12-05T09:17:05Z"  NotOnOrAfter=  "2004-12-05T09:27:05Z"  >  <saml:AudienceRestriction>  <saml:Audience>  https://sp.example.com/ SAML2  </saml:Audience>  </saml:AudienceRestriction> 
        
        
          
          
          
            
          
        
      
    
   </saml:Conditions>  <saml:AuthnStatement  AuthnInstant=  "2004-12-05T09:22:00Z"  SessionIndex=  "identifier_7"  >  <saml:AuthnContext>  <saml:AuthnContextClassRef>  urn:oasis:names:tc:SAML:2.0 :ac:classes:PasswordProtectedTransport  </saml:AuthnContextClassRef>  </saml:AuthnContext>  </saml:AuthnStatement>  </saml:Assertion>  </samlp:Response>  </samlp:ArtifactResponse>

10. Przekieruj do zasobu docelowego

Usługa konsumenta asercji przetwarza odpowiedź, tworzy kontekst bezpieczeństwa u dostawcy usług i przekierowuje agenta użytkownika do zasobu docelowego.

11. Poproś ponownie o zasób docelowy u SP

Agent użytkownika żąda zasobu docelowego od dostawcy usług (ponownie):

https://sp.example.com/myresource

12. Odpowiedz, podając żądany zasób

Ponieważ istnieje kontekst bezpieczeństwa, dostawca usług zwraca zasób agentowi użytkownika.

Profil wykrywania dostawcy tożsamości

W profilu wykrywania dostawcy tożsamości SAML 2.0 wprowadzono następujące pojęcia:

  • Wspólna domena
  • Wspólny plik cookie domeny
  • Wspólna usługa zapisywania plików cookie domeny
  • Wspólna usługa odczytu plików cookie domeny

Jako hipotetyczny przykład domeny Common Domain załóżmy, że Przykład UK (example.co.uk) i Przykład Deutschland (example.de) należą do organizacji wirtualnej Przykład Global Alliance (example.com). W tym przykładzie domena example.com jest domeną wspólną. Zarówno Przykład UK, jak i Przykład Deutschland są obecne w tej domenie (odpowiednio uk.example.com i de.example.com).

Plik cookie domeny wspólnej to bezpieczny plik cookie przeglądarki obejmujący wspólną domenę. Dla każdego użytkownika przeglądarki ten plik cookie przechowuje listę historii ostatnio odwiedzanych dostawców tożsamości. Nazwa i wartość pliku cookie są określone w profilu wykrywania dostawcy tożsamości (SAMLProf).

Po pomyślnym uwierzytelnieniu dostawca tożsamości wysyła żądanie do usługi zapisywania plików cookie domeny Common Domain . Ta usługa dołącza unikalny identyfikator dostawcy tożsamości do wspólnego pliku cookie domeny. Dostawca usług internetowych, gdy otrzyma nieuwierzytelnione żądanie dotyczące chronionego zasobu, żąda od usługi odczytu plików cookie domeny Common Domain odkrycia ostatnio używanego dostawcy tożsamości przez użytkownika przeglądarki.

Profil zapytania/żądania potwierdzenia

Profil zapytania/żądania potwierdzenia to profil ogólny, który obsługuje wiele typów tak zwanych zapytań wykorzystujących następujące elementy SAML 2.0:

  • element <samlp:AssertionIDRequest> , który służy do żądania asercji ze względu na jej unikalny identyfikator ( ID )
  • element <samlp:SubjectQuery> będący abstrakcyjnym punktem rozszerzenia umożliwiającym definiowanie nowych tematycznych zapytań SAML
  • element <samlp:AuthnQuery> , który służy do żądania istniejących potwierdzeń uwierzytelnienia dotyczących danego podmiotu od urzędu uwierzytelniania
  • element <samlp:AttributeQuery> , który służy do żądania atrybutów dotyczących danego tematu od urzędu atrybutu
  • element <samlp:AuthzDecisionQuery> , który służy do żądania decyzji autoryzacyjnej od zaufanej strony trzeciej

Powiązanie SAML SOAP jest często używane w połączeniu z zapytaniami.

Zapytanie o atrybut SAML

Zapytanie o atrybut jest prawdopodobnie najważniejszym typem zapytania SAML. Często osoba żądająca, działająca w imieniu pryncypała, wysyła zapytanie do dostawcy tożsamości o atrybuty. Poniżej podajemy przykład zapytania wystosowanego bezpośrednio przez zleceniodawcę: 

  
    
    
    
    
    
    
      
     <samlp:AttributeQuery  xmlns:saml=  "urn:oasis:names:tc:SAML:2.0:assertion"  xmlns:samlp=  "urn:oasis:names:tc:SAML:2.0:protocol"  ID=  "aaf23196-1773-2113 -474a-fe114412ab72"  Wersja=  "2.0"  IssueInstant=  "2006-07-17T20:31:40Z"  >  <saml:Issuer  Format=  "urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName"  >  [email protected],OU=Użytkownik,O=NCSA-TEST,C=US  </saml:Issuer>  <saml:Subject> 
      
        
    
    
      
      
      
    
    
       <saml:NameID  Format=  "urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName"  >  [email protected],OU=Użytkownik,O=NCSA-TEST,C=US  </saml :NameID>  </saml:Subject>  <saml:Attribute  NameFormat=  "urn:oasis:names:tc:SAML:2.0:attrname-format:uri"  Name=  "urn:oid:2.5.4.42"  FriendlyName=  "nadanaNazwa"  >  </saml:Attribute>  <saml:Attribute  NameFormat=  "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" 
      
      
    
   Name=  "urn:oid:1.3.6.1.4.1.1466.115.121.1.26"  FriendlyName=  "poczta"  >  </saml:Attribute>  </samlp:AttributeQuery>

Należy pamiętać, że w tym przypadku podmiotem jest Emitent . Nazywa się to czasem zapytaniem własnym o atrybut . Dostawca tożsamości może zwrócić następującą asercję zawiniętą w <samlp:Response> (niepokazany): 

  
    
    
    
    
    
    
    
    
     <saml:Assertion  xmlns:saml=  "urn:oasis:names:tc:SAML:2.0:assertion"  xmlns:xs=  "http://www.w3.org/2001/XMLSchema"  xmlns:xsi=  "http:/ /www.w3.org/2001/XMLSchema-instance"  xmlns:ds=  "http://www.w3.org/2000/09/xmldsig#"  ID=  "_33776a319493ad607b7ab3e689482e45"  Wersja=  "2.0"  IssueInstant=  "2006- 07-17T20:31:41Z"  >  <saml:Issuer>  https://idp.example.org/SAML2  </saml:Issuer>  <ds:Signature> 
    
      
        
      
        
        
          
            
              
               ...  </ds:Signature>  <saml:Subject>  <saml:NameID  Format=  "urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName"  >  [email protected],OU= Użytkownik,O=NCSA-TEST,C=US  </saml:NameID>  <saml:SubjectConfirmation  Method=  "urn:oasis:names:tc:SAML:2.0:cm:holder-of-key" > <  saml  :SubjectConfirmationData>  <ds:KeyInfo>  <ds:X509Data>  <!-- certyfikat X.509 zleceniodawcy -->  <ds:X509Certificate>  MIICiDCCAXACCQDE+9eiWrm62jANBgkqhkiG9w0BAQQFADBFMQswCQYDVQQGEwJV UzESMBAGA1UEChMJTkNTQS1URVNUMQ0wCwYDVQQLEwRVc2VyMRMwEQYDVQQDEwpT UC1TZXJ2aWNlMB4XDTA2 MDcxNzIwMjE0MVoXDTA2MDcxODIwMjE0MVowSzELMAkG A1UEBhMCVVMxEjAQBgNVBAoTCU5DU0EtVEVTVDENMAsGA1UECxMEVXNlcjEZMBcG A1UEAwwQdHJzY2F2b0B1aXVjLmVkdTCBnzANBgkqh kiG9w0BAQEFAAOBjQAwgYkC gYEAv9QMe4lRl3XbWPcflbCjGK9gty6zBJmp+tsaJINM0VaBaZ3t+tSXknelYife nCc2O3yaX76aq53QMXy+5wKQYe8Rzdw28Nv3a73wfjXJXoUhGkvERc scs9EfIWcC g2bHOg8uSh+Fbv3lHih4lBJ5MCS2buJfsR7dlr/xsadU2RcCAwEAATANBgkqhkiG 9w0BAQQFAAOCAQEAdyIcMTob7TVkelfJ7+I1j0LO24UlKvbLzd2OPvcFTCv6fVHx Ejk0QxaZXJ hreZ6+rIdiMXrEzlRdJEsNMxtDW8++sVp6avoB5EX1y3ez+CEAIL4g cjvKZUR4dMryWshWIBHKFFul+r7urUgvWI12KbMeE9KP+kiiiiTskLcKgFzngw1J selmHhTcTCrcDocn5yO2+d3dog52vSOtVFDB sBuvDixO2hv679JR6Hlqjtk4GExp E9iVI0wdPE038uQIJJTXlhsMMLvUGVh/c0ReJBn92Vj4dI/yy6PtY/8ncYLYNkjg oVN0J/ymOktn9lTlFyTiuY4OuJsZRO1+ zWLy9g== 
            
          
        
      
    
    
    
      
      
    
    
      
       </ds:X509Certificate>  </ds:X509Data>  </ds:KeyInfo>  </saml:SubjectConfirmationData>  </saml:SubjectConfirmation>  </saml:Subject>  <!-- czas życia asercji ograniczony certyfikatem X.509 zleceniodawcy - ->  <saml:Conditions  NotBefore=  "2006-07-17T20:31:41Z"  NotOnOrAfter=  "2006-07-18T20:21:41Z"  >  </saml:Conditions>  <saml:AuthnStatement  AuthnInstant=  "2006-07- 17T20:31:41Z"  >  <saml:AuthnContext> 
        
      
    
    
      
        
        
        
        
         <saml:AuthnContextClassRef>  urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient  </saml:AuthnContextClassRef>  </saml:AuthnContext>  </saml:AuthnStatement> <  saml:AttributeStatement>  <saml:Attribute  xmlns :x500=  "urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"  x500:Encoding=  "LDAP"  NameFormat=  "urn:oasis:names:tc:SAML:2.0:attrname-format:uri"  Imię=  "urn:oid:2.5.4.42"  FriendlyName=  "nadaneNazwa" 
        
          
      
      
        
        
        
        
        
        
           >  <saml:AttributeValue  xsi:type=  "xs:string"  >  Tom  </saml:AttributeValue>  </saml:Attribute>  <saml:Attribute  xmlns:x500=  "urn:oasis:names:tc:SAML:2.0:profiles :attribute:X500"  x500:Encoding=  "LDAP"  NameFormat=  "urn:oasis:names:tc:SAML:2.0:attrname-format:uri"  Name=  "urn:oid:1.3.6.1.4.1.1466.115.121.1. 26"  FriendlyName=  "poczta"  >  <saml:Wartość atrybutu  xsi:type= 
      
    
   "xs:string"  >  [email protected]  </saml:AttributeValue>  </saml:Attribute>  </saml:AttributeStatement>  </saml:Assertion>

W przeciwieństwie do pokazanej wcześniej BearerAssertion , to potwierdzenie ma dłuższy okres istnienia odpowiadający okresowi istnienia certyfikatu X. 509, którego podmiot zabezpieczeń użył do uwierzytelnienia u dostawcy tożsamości. Co więcej, ponieważ asercja jest podpisana, użytkownik może przekazać to asercję stronie ufającej i dopóki użytkownik może udowodnić posiadanie odpowiedniego klucza prywatnego (stąd nazwa „posiadacz klucza”), strona ufająca może mieć pewność, że twierdzenie jest autentyczne.

Metadane SAML 2.0

Dosłownie metadane sprawiają, że SAML działa (lub działa dobrze). Niektóre ważne zastosowania metadanych obejmują:

  • Dostawca usług przygotowuje się do przesłania elementu <samlp:AuthnRequest> do dostawcy tożsamości za pośrednictwem przeglądarki. Skąd usługodawca wie, że jest autentyczny, a nie jakiś zły dostawca tożsamości próbujący wyłudzić hasło użytkownika? Dostawca usług sprawdza swoją listę zaufanych dostawców tożsamości w metadanych przed wysłaniem żądania uwierzytelnienia.
  • Skąd w poprzednim scenariuszu usługodawca wie, dokąd wysłać użytkownika z prośbą o uwierzytelnienie? Dostawca usług wyszukuje w metadanych wcześniej ustaloną lokalizację punktu końcowego zaufanego dostawcy tożsamości .
  • Dostawca tożsamości otrzymuje element <samlp:AuthnRequest> od dostawcy usług za pośrednictwem przeglądarki. Skąd dostawca tożsamości ma wiedzieć, że jest on autentyczny, a nie jakiś zły usługodawca próbujący zebrać dane osobowe użytkownika? Dostawca tożsamości sprawdza swoją listę zaufanych dostawców usług w metadanych przed wydaniem odpowiedzi uwierzytelniającej.
  • Jak w poprzednim scenariuszu dostawca tożsamości szyfruje potwierdzenie SAML, aby zaufany dostawca usług (i tylko zaufany dostawca usług) mógł odszyfrować potwierdzenie. Dostawca tożsamości używa certyfikatu szyfrowania dostawcy usług w metadanych do szyfrowania potwierdzenia.
  • Kontynuując poprzedni scenariusz, skąd dostawca tożsamości wie, dokąd wysłać użytkownika z odpowiedzią uwierzytelniającą? Dostawca tożsamości wyszukuje w metadanych wcześniej ustaloną lokalizację punktu końcowego zaufanego dostawcy usług .
  • Skąd usługodawca wie, że odpowiedź uwierzytelniająca pochodzi od zaufanego dostawcy tożsamości? Usługodawca weryfikuje podpis na stwierdzeniu wykorzystując klucz publiczny dostawcy tożsamości z metadanych .
  • Skąd dostawca usług wie, gdzie rozwiązać artefakt otrzymany od zaufanego dostawcy tożsamości? Dostawca usług wyszukuje wstępnie ustaloną lokalizację punktu końcowego usługi rozpoznawania artefaktów dostawcy tożsamości na podstawie metadanych .

Metadane zapewniają bezpieczną transakcję pomiędzy dostawcą tożsamości a dostawcą usług. Przed metadanymi informacje o zaufaniu były kodowane w implementacji w sposób zastrzeżony. Obecnie udostępnianie informacji o zaufaniu jest ułatwione dzięki standardowym metadanym. SAML 2.0 zapewnia dobrze zdefiniowany, interoperacyjny format metadanych, który jednostki mogą wykorzystać do uruchomienia procesu zaufania.

Metadane dostawcy tożsamości

Dostawca tożsamości publikuje dane o sobie w elemencie <md:EntityDescriptor> : 

    
    
    
    
    
    
    
        <md:EntityDescriptor  EntityID=  "https://idp.example.org/SAML2"  validUntil=  "2013-03-22T23:00:00Z"  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#"  >  <!-- wstaw ds: Element podpisu (pominięty) -->  <!-- wstaw element md:IDPSSODescriptor (poniżej) -->  <md:Organization>  <md:OrganizationName  xml:lang=  "en" 
       
       
    
     
       >  Niektóre organizacje non-profit z Nowego Jorku  </md:OrganizationName>  <md:OrganizationDisplayName  xml:lang=  "en"  >  Niektóre organizacje non-profit  </md:OrganizationDisplayName>  <md:OrganizationURL  xml:lang=  "en"  >  https://www.example.org/  </md:OrganizationURL>  </md:Organization>  <md:ContactPerson  contactType=  "technical"  >  <md:SurName>  Pomoc techniczna SAML 
      
    
   </md:SurName>  <md:EmailAddress>  mailto:[email protected]  </md:EmailAddress>  </md:ContactPerson>  </md:EntityDescriptor>

Zwróć uwagę na następujące szczegóły dotyczące tego deskryptora encji:

  • EntityID jest unikalnym identyfikatorem jednostki.
  • Atrybut validUntil podaje datę wygaśnięcia metadanych.
  • Element <ds:Signature> (który dla uproszczenia został pominięty) zawiera podpis cyfrowy zapewniający autentyczność i integralność metadanych.
  • Organizacja określona w elemencie <md:Organization> jest „odpowiedzialna za podmiot” opisany przez deskryptor podmiotu (sekcja 2.3.2 SAMLMeta).
  • Dane kontaktowe w elemencie <md:ContactPerson> identyfikują kontakt techniczny odpowiedzialny za podmiot. Możliwych jest wiele kontaktów i typów kontaktów. Zobacz sekcję 2.3.2.2 SAMLMeta.

Z definicji dostawca tożsamości zarządza usługą SSO obsługującą profil SSO przeglądarki internetowej SAML określony w SAMLProf. Zobacz na przykład dostawcę tożsamości opisanego w elemencie <md:IDPSSODescriptor> pokazanym w następnej sekcji.

Metadane usługi SSO

Usługę SSO u dostawcy tożsamości opisano w elemencie <md:IDPSSODescriptor> : 

  
    
     
      
    
      
      
       <md:IDPSSODescriptor  protokółSupportEnumeration=  "urn:oasis:names:tc:SAML:2.0:protocol"  >  <md:KeyDescriptor  use=  "podpisywanie"  >  <ds:KeyInfo>  ...  </ds:KeyInfo>  </md: KeyDescriptor>  <md:ArtifactResolutionService  isDefault=  "true"  indeks=  "0"  Binding=  "urn:oasis:names:tc:SAML:2.0:bindings:SOAP"  Location=  "https://idp.example.org/SAML2/ Rozdzielczość artefaktów”  /> 
    
    
    
      
      
    
      
       <md:NameIDFormat>  urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress  </md:NameIDFormat>  <md:NameIDFormat>  urn:oasis:names:tc:SAML:2.0:nameid-format:transient  </md:NameIDFormat>  <md:SingleSignOnService  Binding=  "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"  Location=  "https://idp.example.org/SAML2/SSO/Redirect"  />  <md:SingleSignOnService  Binding=  "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"  Location= 
    
      
      
    
      
      
      
       "https://idp.example.org/SAML2/SSO/POST"  />  <md:SingleSignOnService  Binding=  "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"  Location=  "https:/ /idp.example.org/SAML2/Artifact"  />  <saml:Attribute  NameFormat=  "urn:oasis:names:tc:SAML:2.0:attrname-format:uri"  Name=  "urn:oid:1.3.6.1.4.1 .5923.1.1.1.1"  FriendlyName=  "eduPersonAffiliation"  >  <saml:AttributeValue>  członek  </saml:AttributeValue> 
      
      
      
      
    
   <Aml: atrybuteValue>  Student  </Aml: atrybutEValue>  <ambena: atrybutEValue>  wykładowca  </saml: atrybutEValue>  <Aml: atrybutEValue>  Pracownik  </saml: atrybteValue>  <Aml: AttributeValue>  Staff  </Aml: atrybuteValue>  <// saml:Attribute>  </md:IDPSSODescriptor>

Poprzedni element metadanych opisuje usługę SSO u dostawcy tożsamości. Zwróć uwagę na następujące szczegóły dotyczące tego elementu:

  • Oprogramowanie dostawcy tożsamości jest skonfigurowane przy użyciu prywatnego klucza podpisywania SAML i/lub prywatnego klucza TLS kanału zwrotnego. Odpowiedni klucz publiczny jest zawarty w elemencie <md:KeyDescriptor use="signing"> w metadanych dostawcy tożsamości. Kluczowy materiał został pominięty w kluczowym deskryptorze dla zwięzłości.
  • Atrybut Binding elementu <md:ArtifactResolutionService> wskazuje, że do rozpoznawania artefaktów należy używać powiązania SAML SOAP (SAMLBind).
  • Atrybut Location elementu <md:ArtifactResolutionService> jest używany w kroku 8 profilu „ podwójny artefakt ”.
  • Wartość atrybutu indeksu elementu <md:ArtifactResolutionService> jest używana jako EndpointIndex podczas konstruowania artefaktu SAML typu 0x0004.
  • Elementy <md:NameIDFormat> wskazują, jakie formaty identyfikatorów nazw SAML (SAMLCore) obsługuje usługa SSO.
  • Atrybuty Binding elementów <md:SingleSignOnService> to standardowe identyfikatory URI określone w specyfikacji wiązania SAML 2.0 (SAMLBind) .
  • Location elementu <md:SingleSignOnService> obsługujący powiązanie HTTP POST jest używany w kroku 2 profilu „ double POST ”.
  • Location elementu <md:SingleSignOnService> , który obsługuje powiązanie artefaktu HTTP, jest używany w kroku 2 profilu „ podwójnego artefaktu ”.
  • Element <saml:Attribute> opisuje atrybut, który dostawca tożsamości chce potwierdzić (z zastrzeżeniem zasad). Elementy <saml:AttributeValue> wyliczają możliwe wartości, jakie może przyjmować atrybut.

Jak wspomniano na początku tej sekcji, wartości atrybutów lokalizacji są wykorzystywane przez dostawcę usług do kierowania komunikatów SAML, co minimalizuje możliwość zorganizowania ataku typu man-in-the-middle przez fałszywego dostawcę tożsamości .

Metadane dostawcy usług

Podobnie jak dostawca tożsamości, dostawca usług publikuje dane o sobie w elemencie <md:EntityDescriptor> : 

    
    
    
    
    
    
    
        <md:EntityDescriptor  EntityID=  "https://sp.example.com/SAML2"  validUntil=  "2013-03-22T23:00:00Z"  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#"  >  <!-- wstaw ds: Element podpisu (pominięty) -->  <!-- wstaw element md:SPSSODescriptor (patrz poniżej) -->  <md:Organization>  <md:OrganizationName  xml:lang=  "en" 
       
       
    
     
       >  Niektórzy dostawcy komercyjni z Kalifornii  </md:OrganizationName>  <md:OrganizationDisplayName  xml:lang=  "en"  >  Niektórzy dostawcy komercyjni  </md:OrganizationDisplayName>  <md:OrganizationURL  xml:lang=  "en"  >  https://www .example.com/  </md:OrganizationURL>  </md:Organization>  <md:ContactPerson  contactType=  "technical"  >  <md:SurName>  Pomoc techniczna SAML  </md:SurName> 
      
    
   <md:EmailAddress>  mailto:[email protected]  </md:EmailAddress>  </md:ContactPerson>  </md:EntityDescriptor>

Zwróć uwagę na następujące szczegóły dotyczące tego deskryptora encji:

  • EntityID jest unikalnym identyfikatorem jednostki.
  • Atrybut validUntil podaje datę wygaśnięcia metadanych.
  • Element <ds:Signature> (który dla uproszczenia został pominięty) zawiera podpis cyfrowy zapewniający autentyczność i integralność metadanych.
  • Organizacja określona w elemencie <md:Organization> jest „odpowiedzialna za podmiot” opisany przez deskryptor podmiotu (sekcja 2.3.2 SAMLMeta).
  • Dane kontaktowe w elemencie <md:ContactPerson> identyfikują kontakt techniczny odpowiedzialny za podmiot. Możliwych jest wiele kontaktów i typów kontaktów. Zobacz sekcję 2.3.2.2 SAMLMeta.

Z definicji dostawca usług zarządza usługą konsumencką asercji, która obsługuje profil SSO przeglądarki internetowej SAML określony w SAMLProf. Zobacz na przykład dostawcę usług opisanego w elemencie <md:SPSSODescriptor> pokazanym w następnej sekcji.

Metadane usług konsumenckich potwierdzenia

Usługa konsumenta asercji jest zawarta w elemencie <md:SPSSODescriptor> : 

  
    
     
      
    
     
      
    
       <md:SPSSODescriptor  protokółSupportEnumeration=  "urn:oasis:names:tc:SAML:2.0:protocol"  >  <md:KeyDescriptor  use=  "podpisywanie"  >  <ds:KeyInfo>  ...  </ds:KeyInfo>  </md: KeyDescriptor>  <md:KeyDescriptor  use=  "szyfrowanie"  >  <ds:KeyInfo>  ...  </ds:KeyInfo>  </md:KeyDescriptor>  <md:ArtifactResolutionService  isDefault=  "true"  indeks= 
      
      
    
    
      
       „0”  Binding=  „urn:oasis:names:tc:SAML:2.0:bindings:SOAP”  Location=  „https://sp.example.com/SAML2/ArtifactResolution”  />  <md:NameIDFormat>  urn:oasis: Names:tc:SAML:1.1:nameid-format:emailAddress  </md:NameIDFormat>  <md:NameIDFormat>  urn:oasis:names:tc:SAML:2.0:nameid-format:transient  </md:NameIDFormat>  <md: AssertionConsumerService  isDefault=  "true"  indeks=  "0"  Binding= 
      
     
      
      
      
        „urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST”  Lokalizacja=  „https://sp.example.com/SAML2/SSO/POST”  />  <md:AssertionConsumerService  indeks=  „1”  Powiązanie =  "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"  Lokalizacja=  "https://sp.example.com/SAML2/Artifact"  />  <md:AttributeConsumingService  isDefault=  "true"  indeks=  "1"  >  <md:NazwaUsługi  xml:lang=  "en"  > 
      
        
        
        
      
    
   Portal dostawców usług  </md:ServiceName>  <md:RequestedAttribute  NameFormat=  "urn:oasis:names:tc:SAML:2.0:attrname-format:uri"  Name=  "urn:oid:1.3.6.1.4.1.5923.1.1.1 .1"  FriendlyName=  "eduPersonAffiliation"  >  </md:RequestedAttribute>  </md:AttributeConsumingService>  </md:SPSSODescriptor>

Zwróć uwagę na następujące szczegóły dotyczące elementu metadanych <md:SPSSODescriptor> :

  • Oprogramowanie dostawcy usług jest skonfigurowane przy użyciu prywatnego klucza podpisywania SAML i/lub prywatnego klucza TLS kanału zwrotnego. Odpowiedni klucz publiczny jest zawarty w elemencie <md:KeyDescriptor use="signing"> w metadanych SP. Kluczowy materiał został pominięty w kluczowym deskryptorze dla zwięzłości.
  • Podobnie oprogramowanie usługodawcy jest skonfigurowane z prywatnym kluczem deszyfrującym SAML. Publiczny klucz szyfrowania SAML jest zawarty w elemencie <md:KeyDescriptor use="encryption"> w metadanych SP. Kluczowy materiał został pominięty w kluczowym deskryptorze dla zwięzłości.
  • Atrybut indeksu elementu <md:AssertionConsumerService> jest używany jako wartość atrybutu AssertionConsumerServiceIndex w elemencie <samlp:AuthnRequest> .
  • Binding elementów <md:AssertionConsumerService> to standardowe identyfikatory URI określone w specyfikacji wiązania SAML 2.0 (SAMLBind) .
  • Atrybut Location elementu <md:AssertionConsumerService> , który obsługuje powiązanie HTTP POST ( index="0" ) jest używany w kroku 4 profilu „ double POST ”.
  • Atrybut Location elementu <md:AssertionConsumerService> , który obsługuje powiązanie artefaktu HTTP ( indeks="1" ) jest używany w kroku 6 profilu „ podwójnego artefaktu ”.
  • Element <md:AttributeConsumingService> jest używany przez dostawcę tożsamości do formułowania elementu <saml:AttributeStatement> , który jest przesyłany do dostawcy usług w połączeniu z logowaniem jednokrotnym przeglądarki internetowej.
  • Atrybut indeksu elementu <md:AttributeConsumingService> jest używany jako wartość atrybutu AttributeConsumingServiceIndex w elemencie <samlp:AuthnRequest> .

Jak wspomniano na początku tej sekcji, wartości atrybutów lokalizacji są wykorzystywane przez dostawcę tożsamości do kierowania komunikatów SAML, co minimalizuje możliwość zorganizowania przez nieuczciwego dostawcę usług ataku typu „man-in-the-middle” .

Agregacje metadanych

W poprzednich przykładach każdy element <md:EntityDescriptor> jest podpisany cyfrowo. W praktyce jednak wiele <md:EntityDescriptor> jest grupowanych razem w ramach elementu <md:EntitiesDescriptor> z pojedynczym podpisem cyfrowym na całym zbiorze: 

   
    
    
    
    
     
      <md:EntitiesDescriptor  validUntil=  "2013-03-22T23:00:00Z"  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#"  >  <!-- wstaw ds:Element podpisu (pominięty) -->  <md:EntityDescriptor  EntityID=  " https://idp.example.org/SAML2"  >  ...  </md:EntityDescriptor>  <md:EntityDescriptor  EntityID= 
   „https://sp.example.com/SAML2”  >  ...  </md:EntityDescriptor>  </md:EntitiesDescriptor>

Zwróć uwagę na następujące szczegóły dotyczące powyższego elementu <md:EntitiesDescriptor> :

  • Podpis cyfrowy (który dla uproszczenia pominięto) obejmuje cały agregat.
  • validUntil XML został podniesiony do elementu nadrzędnego, co oznacza, że ​​data wygaśnięcia dotyczy każdego elementu podrzędnego .
  • Deklaracje przestrzeni nazw XML zostały podniesione do elementu nadrzędnego, aby uniknąć zbędnych deklaracji przestrzeni nazw.

Zazwyczaj agregaty metadanych są publikowane przez zaufane strony trzecie zwane federacjami , które gwarantują integralność wszystkich metadanych w zbiorze. Należy pamiętać, że agregaty metadanych mogą być bardzo duże i składać się z setek, a nawet tysięcy jednostek na agregat.

Zobacz też

Podstawowe referencje:

Dodatkowe odniesienia:

Przestarzałe odniesienia:

Pobrano z „ https://en.wikipedia.org/w/index.php?title=SAML_2.0&oldid=1115283072 ”