Zasady SAMLAssertion

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X. informacje.

Co

• Przychodzące uwierzytelnianie i autoryzacja: potwierdzanie asercji SAML zasada
  Typ zasady SAML umożliwia serwerom proxy interfejsu API walidację asercji SAML podłączonych do przychodzące żądania SOAP. Zasada SAML weryfikuje wiadomości przychodzące zawierające podpisane cyfrowo asercja SAML, odrzuca je, jeśli są nieprawidłowe, i ustawia zmienne, które zezwalanie na dodatkowe zasady lub same usługi backendu w celu dalszej weryfikacji informacji. w sferze asercji.
• Generowanie tokena wychodzącego: generowanie zasad asercji SAML
  Typ zasady SAML umożliwia serwerom proxy interfejsu API dołączanie potwierdzeń SAML do wychodzących żądań XML. Następnie dostępne są asercje, aby umożliwić usługom backendu możliwość stosowania dalszych zabezpieczeń uwierzytelnianie i autoryzacja.

Przykłady

<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

Wygeneruj asercję SAML

Weryfikacja asercji SAML

Zastosowanie

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

„Potwierdzenie zabezpieczeń” to zaufany token opisujący atrybut aplikacji, użytkownika lub innego uczestnika transakcji. 2 potwierdzenia zabezpieczeń są zarządzane i wykorzystywane przez typy podmiotów:

• Dostawcy tożsamości: generuj potwierdzenia zabezpieczeń w imieniu uczestników
• Dostawcy usług: weryfikuj potwierdzenia bezpieczeństwa za pomocą zaufanych relacji z tożsamością usługodawcy

Platforma interfejsów API może działać jako dostawca tożsamości i usługodawca. Pełni ona rolę dostawcy tożsamości przez generowanie asercji i dołączanie ich do żądań wiadomości, dzięki czemu te asercje dostępne do przetwarzania przez usługi backendu. Jest to dostawca usług, który: weryfikacji asercji w wiadomościach przychodzących.

Typ zasad SAML obsługuje asercje SAML zgodne z wersją 2.0 funkcji SAML Core Specyfikacja i wersja 1.0 specyfikacji profilu tokenów SAML WS-Security.

Wygeneruj asercję SAML

Przetwarzanie zasad:

1. Jeśli komunikat nie jest w formacie XML, a parametr ignoreContentType nie ma wartości true, zgłosić błąd.
2. Jeśli "Szablon" a następnie przetwórz szablon zgodnie z opisem zasady AssignMessage. Jeśli brakuje jakichś zmiennych, a parametr ignoreUnresolvedvariables nie jest ustawiony, zgłoś błąd.
3. Jeśli "Szablon" nie jest ustawiona, utwórz asercję, która zawiera wartości argumentu Parametry podmiotu i wystawcy lub ich odwołania.
4. Podpisz asercję za pomocą podanego klucza.
5. Dodaj potwierdzenie do wiadomości w podanej ścieżce XPath.

Weryfikacja asercji SAML

Przetwarzanie zasad:

1. Zasada sprawdza wiadomość przychodzącą, aby zweryfikować, czy typ mediów żądania to XML. sprawdzanie, czy typ treści pasuje do formatów text/(.*+)?xml lub application/(.*+)?xml Jeśli typem nośnika jest inny niż XML i <IgnoreContentType> nie jest skonfigurowany, zasada będzie zgłaszać błąd.
2. Zasada przeanalizuje kod XML. Jeśli analiza się nie uda, spowoduje to zgłoszenie błędu.
3. Zasada wyodrębnia podpisany element i asercję przy użyciu odpowiednich ścieżek XPath (<SignedElementXPath> i <AssertionXPath>). Jeśli żadna z tych ścieżek nie zwróci elementu, zasada zwróci błąd.
4. Zasada sprawdzi, czy asercja jest taka sama jak podpisany element. element podrzędny elementu podpisanego. Jeśli tak nie jest, zasada powoduje zgłoszenie błędu.
5. Jeśli <NotBefore> lub <NotOnOrAfter> w asercji są obecne elementy, zasada sprawdzi bieżącą sygnaturę czasową te wartości są opisane w sekcji 2.5.1 SAML Core.
6. Te zasady będą miały zastosowanie do wszystkich dodatkowych reguł przetwarzania „Warunków” zgodnie z opisem w sekcji 2.5.1.1 SAML Core.
7. Zasada sprawdzi podpis cyfrowy XML przy użyciu wartości <TrustStore> i <ValidateSigner>, jak opisano powyżej. Jeśli weryfikacja się nie powiedzie, zasada zwróci błąd.

Po zakończeniu działania zasad bez zgłaszania błędu deweloper serwera proxy może mieć pewność, spośród następujących:

• Podpis cyfrowy na potwierdzeniu jest prawidłowy i został podpisany przez zaufany urząd certyfikacji
• Potwierdzenie jest prawidłowe dla bieżącego okresu
• Podmiot i wydawca asercji zostaną wyodrębnione i ustawione w zmiennych przepływu. Jest innych zasad za używanie tych wartości na potrzeby dodatkowego uwierzytelniania, takich jak sprawdzając poprawność nazwy podmiotu lub przekazując ją do systemu docelowego w celu weryfikacji.

Do analizowania nieprzetworzonego kodu XML asercji można używać innych zasad, takich jak ExtractZmienne do bardziej złożonej weryfikacji.

Zmienne przepływu

Potwierdzenie SAML może zawierać wiele informacji. SAML Sama asercja to kod XML, który może być przeanalizowany przy użyciu zasady Extractvariables i innych za pomocą bardziej złożonych mechanizmów weryfikacji.

Informacje o błędzie

W tej sekcji opisano zwracane kody błędów i komunikaty o błędach i zmiennych błędów, które są ustawiane przez Edge, gdy ta zasada wywołuje błąd. Warto o tym wiedzieć, jeśli rozwijasz reguły błędów, aby obsługi błędów. Więcej informacji znajdziesz w artykule Co musisz wiedzieć o błędach związanych z zasadami i postępowaniu z błędami

Błędy wdrażania

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

Zmienne błędów

Te zmienne są ustawiane po wystąpieniu błędu działania. Więcej informacji znajdziesz w artykule Podstawowe informacje 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: Wyodrębnianie zmiennych