Zasady SAMLAssertion

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info

Co

• Zasada Inbound authentication and authorization: Validate SAML Assertion
  Typ zasady SAML umożliwia serwerom proxy interfejsu API weryfikowanie asercji SAML dołączonych do przychodzących żądań SOAP. Zasady SAML sprawdzają przychodzące wiadomości zawierające podpisane cyfrowo potwierdzenie SAML, odrzucają je, jeśli są nieprawidłowe, i ustawiają zmienne, które umożliwiają dodatkowym zasadom lub usługom backendu dalsze sprawdzanie informacji w potwierdzeniu.
• Generowanie tokenów wychodzących: zasady generowania asercji SAML
  Typ zasad SAML umożliwia serwerom proxy interfejsu API dołączanie asercji SAML do wychodzących żądań XML. Te potwierdzenia są następnie dostępne, aby umożliwić usługom backendu stosowanie dodatkowych zabezpieczeń w celu uwierzytelniania i autoryzacji.

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

Generowanie asercji SAML

Weryfikowanie asercji SAML

Zastosowanie

Specyfikacja SAML (Security Assertion Markup Language) określa formaty i protokoły, które umożliwiają aplikacjom wymianę informacji w formacie XML na potrzeby uwierzytelniania i autoryzacji.

„Asercja bezpieczeństwa” to zaufany token, który opisuje atrybut aplikacji, użytkownika aplikacji lub innego uczestnika transakcji. Asercje zabezpieczeń są zarządzane i wykorzystywane przez 2 rodzaje podmiotów:

• Dostawcy tożsamości: generowanie potwierdzeń bezpieczeństwa w imieniu uczestników
• Dostawcy usług: weryfikowanie potwierdzeń bezpieczeństwa za pomocą zaufanych relacji z dostawcami tożsamości

Platforma interfejsu API może pełnić rolę dostawcy tożsamości i dostawcy usług. Pełni rolę dostawcy tożsamości, generując asercje i dołączając je do wiadomości z żądaniami, dzięki czemu są one dostępne do przetwarzania przez usługi backendu. Pełni rolę dostawcy usług, ponieważ weryfikuje potwierdzenia w przychodzących wiadomościach z żądaniami.

Typ zasady SAML obsługuje asercje SAML zgodne z wersją 2.0 specyfikacji SAML Core i wersją 1.0 specyfikacji WS-Security SAML Token Profile.

Generowanie asercji SAML

Przetwarzanie zasad:

1. Jeśli wiadomość nie jest w formacie XML, a parametr IgnoreContentType nie ma wartości true, zgłoś błąd.
2. Jeśli ustawiona jest opcja „Template”, szablon jest przetwarzany zgodnie z opisem w przypadku zasady AssignMessage. Jeśli brakuje zmiennych, a parametr IgnoreUnresolvedVariables nie jest ustawiony, zgłoś błąd.
3. Jeśli parametr „Template” nie jest ustawiony, utwórz potwierdzenie zawierające wartości parametrów Subject i Issuer lub ich odwołania.
4. Podpisz asercję za pomocą określonego klucza.
5. Dodaj asercję do wiadomości w określonym XPath.

Weryfikowanie asercji SAML

Przetwarzanie zasad:

1. Zasada sprawdza wiadomość przychodzącą, aby zweryfikować, czy typ nośnika żądania to XML. W tym celu sprawdza, czy typ treści jest zgodny z formatami text/(.*+)?xml lub application/(.*+)?xml. Jeśli typ nośnika nie jest XML-em i atrybut <IgnoreContentType> nie jest skonfigurowany, zasada zgłosi błąd.
2. Zasada przeanalizuje kod XML. Jeśli analiza się nie powiedzie, zgłosi błąd.
3. Zasady wyodrębniają podpisany element i asercję, używając odpowiednich ścieżek XPath (<SignedElementXPath> i <AssertionXPath>). Jeśli któraś z tych ścieżek nie zwraca elementu, zasady zgłaszają błąd.
4. Zasady sprawdzą, czy potwierdzenie jest takie samo jak podpisany element lub czy jest elementem podrzędnym podpisanego elementu. Jeśli tak nie jest, zasada zgłosi błąd.
5. Jeśli w asercji występuje element <NotBefore> lub <NotOnOrAfter>, zasada sprawdzi bieżący sygnaturę czasową w porównaniu z tymi wartościami zgodnie z sekcją 2.5.1 specyfikacji SAML Core.
6. Zasady będą stosować wszelkie dodatkowe reguły przetwarzania „Warunków” zgodnie z opisem w sekcji 2.5.1.1 standardu SAML Core.
7. Zasada weryfikuje podpis cyfrowy XML za pomocą wartości magazynu zaufanych certyfikatów (<TrustStore>) opisanej powyżej. Jeśli weryfikacja się nie powiedzie, zasady zgłoszą błąd.

Gdy zasada zostanie wykonana bez zgłaszania błędów, deweloper serwera proxy może mieć pewność, że:

• Podpis cyfrowy w asercji jest ważny i został podpisany przez zaufany urząd certyfikacji.
• Asercja jest ważna w bieżącym okresie.
• Temat i wystawca asercji zostaną wyodrębnione i ustawione w zmiennych przepływu. Za używanie tych wartości do dodatkowego uwierzytelniania, np. sprawdzania, czy nazwa podmiotu jest prawidłowa, lub przekazywania jej do systemu docelowego w celu weryfikacji, odpowiadają inne zasady.

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

Zmienne przepływu

Potwierdzenie SAML może zawierać wiele informacji. Sama asercja SAML to XML, który można przeanalizować za pomocą zasady ExtractVariables i innych mechanizmów, aby wdrożyć bardziej złożone weryfikacje.

Odwołanie do błędu

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: zasady Extract Variables