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

This section describes the fault codes and error messages that are returned and fault variables that are set by Edge when this policy triggers an error. This information is important to know if you are developing fault rules to handle faults. To learn more, see What you need to know about policy errors and Handling faults.

Deployment errors

These errors can occur when you deploy a proxy containing this policy.

Fault variables

These variables are set when a runtime error occurs. For more information, see What you need to know about policy errors.

Example error response

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

Example fault rule

<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