Zasady SAMLAssertion

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

Co

• Uwierzytelnianie i autoryzacja przychodzącego: sprawdzanie zasady asercji SAML
  Typ zasady SAML pozwala serwerom proxy interfejsu API sprawdzać potwierdzenia SAML dołączone do przychodzących żądań SOAP. Zasada SAML weryfikuje wiadomości przychodzące zawierające cyfrowo podpisane potwierdzenie SAML, odrzuca je, jeśli są nieprawidłowe, i ustawia zmienne zezwalające na dodatkowe zasady lub same usługi backendu w celu dalszej weryfikacji informacji zawartych w asercji.
• Wychodzące tokeny generowania tokenów – generowanie zasad potwierdzania SAML
  Typ zasady SAML pozwala serwerom proxy interfejsu API dołączać potwierdzenia SAML do wychodzących żądań XML. Te asercje są wtedy dostępne, aby umożliwić usługom backendu zastosowanie dodatkowego przetwarzania zabezpieczeń podczas uwierzytelniania i autoryzacji.

Sample

<GenerateSAMLAssertion name="SAML" ignoreContentType="false">
  <CanonicalizationAlgorithm />
  <Issuer ref="reference">Issuer name</Issuer>
  <KeyStore>
    <Name ref="reference">keystorename</Name>
    <Alias ref="reference">alias</Alias>
  </KeyStore>
  <OutputVariable>
    <FlowVariable>assertion.content</FlowVariable>
    <Message name="request">
      <Namespaces>
        <Namespace prefix="test">http://www.example.com/test</Namespace>
      </Namespaces>
      <XPath>/envelope/header</XPath>
    </Message>
  </OutputVariable>
  <SignatureAlgorithm />
  <Subject ref="reference">Subject name</Subject>
  <Template ignoreUnresolvedVariables="false">
    <!-- A lot of XML goes here, in CDATA, with {} around
         each variable -->
  </Template>
</GenerateSAMLAssertion>

<ValidateSAMLAssertion name="SAML" ignoreContentType="false">
  <Source name="request">
    <Namespaces>
      <Namespace prefix='soap'>http://schemas.xmlsoap.org/soap/envelope/</Namespace>
      <Namespace prefix='wsse'>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd</Namespace>
      <Namespace prefix='saml'>urn:oasis:names:tc:SAML:2.0:assertion</Namespace>
    </Namespaces>
    <AssertionXPath>/soap:Envelope/soap:Header/wsse:Security/saml:Assertion</AssertionXPath>
    <SignedElementXPath>/soap:Envelope/soap:Header/wsse:Security/saml:Assertion</SignedElementXPath>
  </Source>
  <TrustStore>TrustStoreName</TrustStore>
  <RemoveAssertion>false</RemoveAssertion>
</ValidateSAMLAssertion>

Odwołanie do elementu

Generowanie potwierdzenia SAML

Weryfikowanie potwierdzenia SAML

Zastosowanie

Specyfikacja SAML (Security Assertion Markup Language) definiuje formaty i protokoły umożliwiające aplikacjom wymianę informacji w formacie XML na potrzeby uwierzytelniania i autoryzacji.

„Asercja zabezpieczeń” to zaufany token opisujący atrybut aplikacji, użytkownika aplikacji lub innego uczestnika transakcji. Potwierdzenia zabezpieczeń są zarządzane i wykorzystywane przez 2 typy encji:

• Dostawcy tożsamości: generowanie potwierdzeń zabezpieczeń w imieniu uczestników
• Dostawcy usług: weryfikowanie twierdzeń zabezpieczeń przez zaufane relacje z dostawcami tożsamości

Platforma interfejsów API może działać jako dostawca tożsamości i dostawca usług. Działa jako dostawca tożsamości, generując asercje i dołączając je do żądań wiadomości, dzięki czemu usługi backendu mogą je przetwarzać. Działa jako dostawca usług przez weryfikowanie asercji w wiadomościach przychodzących żądań.

Typ zasady SAML obsługuje potwierdzenia SAML zgodne z wersją 2.0 specyfikacji SAML Core i wersją 1.0 specyfikacji profilu tokena SAML WS-Security.

Generowanie potwierdzenia SAML

Przetwarzanie zasad:

1. Jeśli komunikat nie jest w formacie XML, a parametr IgnorujContentType nie ma wartości true, zgłoś błąd.
2. Jeśli ustawiona jest wartość „Template”, przetwórz szablon zgodnie z opisem w przypadku zasady AssignMessage. Jeśli brakuje jakichkolwiek zmiennych, a zmienna IgnorujUnresolvedVariables nie jest ustawiona, zgłoś błąd.
3. Jeśli szablon „Template” nie jest ustawiony, utwórz asercję obejmującą wartości parametrów Subject i Issuer lub ich odwołania.
4. Podpisz asercję za pomocą podanego klucza.
5. Dodaj potwierdzenie do wiadomości w podanej ścieżce XPath.

Weryfikowanie potwierdzenia SAML

Przetwarzanie zasad:

1. Zasada sprawdza wiadomość przychodzącą, aby potwierdzić, że typ nośnika żądania to XML. W tym celu sprawdza, czy typ treści jest zgodny z formatem text/(.*+)?xml lub application/(.*+)?xml. Jeśli typ nośnika jest inny niż XML, a zasada <IgnoreContentType> nie jest ustawiona, zasada zgłasza błąd.
2. Zasada przeanalizuje plik XML. Jeśli analiza nie powiedzie się, spowoduje to błąd.
3. Zasada wyodrębni podpisany element i asercję przy użyciu odpowiednich określonych ścieżek XPath (<SignedElementXPath> i <AssertionXPath>). Jeśli żadna z tych ścieżek nie zwróci elementu, zasada zgłosi błąd.
4. Zasada sprawdzi, czy asertion jest taki sam jak podpisany element lub jest elementem podrzędnym tego elementu. Jeśli ten warunek nie zostanie spełniony, zasady powodują błąd.
5. Jeśli asercja zawiera jeden z elementów <NotBefore> lub <NotOnOrAfter>, zasada sprawdza bieżącą sygnaturę czasową z tymi wartościami, jak opisano w sekcji dotyczącej podstawowego SAML 2.5.1.
6. W ramach zasad będą stosowane wszelkie dodatkowe reguły przetwarzania „Warunków” opisane w sekcji 2.5.1.1 dotyczącej SAML.
7. Ta zasada weryfikuje podpis cyfrowy XML przy użyciu wartości <TrustStore> i <ValidateSigner>, jak opisano powyżej. Jeśli weryfikacja się nie powiedzie, zasada zgłosi błąd.

Gdy zasada zostanie skonfigurowana bez występowania błędu, deweloper serwera proxy ma pewność, że:

• Podpis cyfrowy potwierdzenia jest prawidłowy i został podpisany przez zaufany urząd certyfikacji
• Asercja jest prawidłowa w bieżącym okresie
• Podmiot i wystawca potwierdzenia zostanie wyodrębniony i ustawiony w zmiennych procesu. Obowiązkiem innych zasad jest użycie tych wartości do dodatkowego uwierzytelniania, np. sprawdzenie, czy nazwa podmiotu jest poprawna, lub przekazanie jej do docelowego systemu w celu weryfikacji.

Inne zasady, takie jak ExtractZmienne, mogą być używane do analizowania nieprzetworzonego kodu XML potwierdzenia w celu bardziej złożonej weryfikacji.

Zmienne przepływu

Potwierdzenie SAML może zawierać wiele informacji. Samo potwierdzenie SAML to kod XML, który można analizować za pomocą zasady ExtractVariables i innych mechanizmów w celu zaimplementowania bardziej złożonych weryfikacji.

Informacje o błędach

W tej sekcji opisujemy kody błędów i komunikaty o błędach, które są zwracane, a także zmienne błędów ustawiane przez Edge, gdy ta zasada aktywuje błąd. Te informacje są ważne, jeśli opracowujesz reguły dotyczące błędów do obsługi takich błędów. Więcej informacji znajdziesz w sekcjach Co musisz wiedzieć o błędach zasad i Postępowanie w przypadku błędów.

Błędy wdrażania

Te błędy mogą wystąpić podczas wdrażania serwera proxy zawierającego te zasady.

Zmienne błędów

Te zmienne są ustawiane, gdy wystąpi błąd środowiska wykonawczego. Więcej informacji znajdziesz w artykule Co musisz wiedzieć o błędach związanych z naruszeniem zasad.

Przykładowa odpowiedź na błąd

{
  "fault": {
    "faultstring": "GenerateSAMLAssertion[GenSAMLAssert]: Invalid media type",
    "detail": {
      "errorcode": "steps.saml.generate.InvalidMediaTpe"
    }
  }
}

Przykładowa reguła błędu

<FaultRules>
    <FaultRule name="invalid_saml_rule">
        <Step>
            <Name>invalid-saml</Name>
        </Step>
        <Condition>(GenerateSAMLAssertion.failed = "true")</Condition>
    </FaultRule>
</FaultRules>

Powiązane artykuły

Wyodrębnianie zmiennych: zasady wyodrębniania zmiennych