[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-27。"],[[["\u003cp\u003eThis page provides information on the SAML policy, which is applicable to both Apigee and Apigee hybrid environments.\u003c/p\u003e\n"],["\u003cp\u003eThe SAML policy enables API proxies to validate SAML assertions attached to inbound SOAP requests, ensuring message validity and enabling further security checks.\u003c/p\u003e\n"],["\u003cp\u003eThe SAML policy also allows API proxies to generate and attach SAML assertions to outbound XML requests, facilitating secure backend service interactions.\u003c/p\u003e\n"],["\u003cp\u003eThe policy supports both acting as an identity provider (generating assertions) and a service provider (validating assertions) in the context of SAML-based authentication and authorization.\u003c/p\u003e\n"],["\u003cp\u003eDeployment errors with the SAML policy are outlined, such as \u003ccode\u003eSourceNotConfigured\u003c/code\u003e, \u003ccode\u003eTrustStoreNotConfigured\u003c/code\u003e, and \u003ccode\u003eNullKeyStoreAlias\u003c/code\u003e, including their causes and detailed troubleshooting guidance.\u003c/p\u003e\n"]]],[],null,["# SAMLAssertion policies\n\n*This page\napplies to **Apigee** and **Apigee hybrid**.*\n\n\n*View [Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) documentation.*\n\n### What\n\n- **Inbound authentication and authorization: Validate SAML Assertion\n policy** \n The SAML policy type enables API proxies to validate SAML assertions that are attached to inbound SOAP requests. The SAML policy validates incoming messages that contain a digitally-signed SAML assertion, rejects them if they are invalid, and sets variables that allow additional policies, or the backend services itself, to further validate the information in the assertion.\n- **Outbound token generation: Generate SAML Assertion policy** \n The SAML policy type enables API proxies to attach SAML assertions to outbound XML requests. Those assertions are then available to enable backend services to apply further security processing for authentication and authorization.\n\nThis policy is an *Extensible policy* and use of this policy might have cost or\nutilization implications, depending on your Apigee license. For information on policy types\nand usage implications, see\n[Policy types](/apigee/docs/api-platform/reference/policies/reference-overview-policy#policy-types).\n\n### Samples\n\n### Generate SAML assertion\n\n```vb.net\n\u003cGenerateSAMLAssertion name=\"SAML\" ignoreContentType=\"false\"\u003e\n \u003cCanonicalizationAlgorithm /\u003e\n \u003cIssuer ref=\"reference\"\u003eIssuer name\u003c/Issuer\u003e\n \u003cKeyStore\u003e\n \u003cName ref=\"reference\"\u003ekeystorename\u003c/Name\u003e\n \u003cAlias ref=\"reference\"\u003ealias\u003c/Alias\u003e\n \u003c/KeyStore\u003e\n \u003cOutputVariable\u003e\n \u003cFlowVariable\u003eassertion.content\u003c/FlowVariable\u003e\n \u003cMessage name=\"request\"\u003e\n \u003cNamespaces\u003e\n \u003cNamespace prefix=\"soap\"\u003ehttp://schemas.xmlsoap.org/soap/envelope/\u003c/Namespace\u003e\n \u003cNamespace prefix='wsse'\u003ehttp://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\u003c/Namespace\u003e\n \u003c/Namespaces\u003e\n \u003cXPath\u003e/soap:Envelope/soap:Header/wsse:Security\u003c/XPath\u003e\n \u003c/Message\u003e\n \u003c/OutputVariable\u003e\n \u003cSignatureAlgorithm /\u003e\n \u003cSubject ref=\"reference\"\u003eSubject name\u003c/Subject\u003e\n \u003cTemplate ignoreUnresolvedVariables=\"false\"\u003e\n \u003c!-- A lot of XML goes here, within CDATA, with {} around\n each variable --\u003e\n \u003c/Template\u003e\n\u003c/GenerateSAMLAssertion\u003e\n```\n\nGenerating a SAML assertion\n\n### Validate SAML assertion\n\n```vb.net\n\u003cValidateSAMLAssertion name=\"SAML\" ignoreContentType=\"false\"\u003e\n \u003cSource name=\"request\"\u003e\n \u003cNamespaces\u003e\n \u003cNamespace prefix='soap'\u003ehttp://schemas.xmlsoap.org/soap/envelope/\u003c/Namespace\u003e\n \u003cNamespace prefix='wsse'\u003ehttp://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\u003c/Namespace\u003e\n \u003cNamespace prefix='saml'\u003eurn:oasis:names:tc:SAML:2.0:assertion\u003c/Namespace\u003e\n \u003c/Namespaces\u003e\n \u003cAssertionXPath\u003e/soap:Envelope/soap:Header/wsse:Security/saml:Assertion\u003c/AssertionXPath\u003e\n \u003cSignedElementXPath\u003e/soap:Envelope/soap:Header/wsse:Security/saml:Assertion\u003c/SignedElementXPath\u003e\n \u003c/Source\u003e\n \u003cTrustStore\u003eTrustStoreName\u003c/TrustStore\u003e\n \u003cRemoveAssertion\u003efalse\u003c/RemoveAssertion\u003e\n\u003c/ValidateSAMLAssertion\u003e\n```\n\nValidating a SAML assertion\n\n*** ** * ** ***\n\nElement reference\n-----------------\n\n### Generate SAML Assertion\n\n### Validate SAML Assertion\n\n*** ** * ** ***\n\nUsage notes\n-----------\n\nThe Security Assertion Markup Language (SAML) specification defines formats and protocols that\nenable applications to exchange XML-formatted information for authentication and\nauthorization.\n\nA \"security assertion\" is a trusted token that describes an attribute of an app, an app user,\nor some other participant in a transaction. Security assertions are managed and consumed by two\ntypes of entities:\n\n- Identity providers: Generate security assertions on behalf of participants\n- Service providers: Validate security assertions through trusted relationships with identity providers\n\nThe API platform can act as an identity provider and as a service provider. It acts as an\nidentity provider by generating assertions and attaching them to request messages, making those\nassertions available for processing by backend services. It acts as a service provider by\nvalidating assertions on inbound request messages.\n\nThe SAML policy type supports SAML assertions that match version 2.0 of the SAML Core\nSpecification and Version 1.0 of the WS-Security SAML Token Profile specification.\n\n### Generate SAML Assertion\n\nPolicy processing:\n\n1. If the message is not XML, and IgnoreContentType is not set to `true`, then raise a fault.\n2. If \"Template\" is set, then process the template as described for the AssignMessage policy. If any variables are missing and IgnoreUnresolvedVariables is not set, then raise a fault.\n3. If \"Template\" is not set, then construct an assertion that includes the values of the Subject and Issuer parameters or their references.\n4. Sign the assertion using the specified key.\n5. Add the assertion to the message at the specified XPath.\n\n### Validate SAML Assertion\n\nPolicy processing:\n\n1. The policy checks the inbound message to verify that the request's media type is XML, by checking if the content type matches the formats `text/(.*+)?xml` or `application/(.*+)?xml`. If the media type is not XML and `\u003cIgnoreContentType\u003e` is not set, then the policy will raise a fault.\n2. The policy will parse the XML. If parsing fails then it will raise a fault.\n3. The policy will extract the signed element and the assertion, using the respective XPaths specified (`\u003cSignedElementXPath\u003e` and `\u003cAssertionXPath\u003e`). If either of these paths do not return an element, then the policy will raise a fault.\n4. The policy will verify that the Assertion is the same as the signed element, or is a child of the signed element. If this is not true, then the policy will raise a fault.\n5. If either of the `\u003cNotBefore\u003e` or `\u003cNotOnOrAfter\u003e` elements are present in the assertion, the policy will check the current timestamp against these values, as described in SAML Core section 2.5.1.\n6. The policy will apply any additional rules for processing the \"Conditions\" as described in SAML Core section 2.5.1.1.\n7. The policy will validate the XML digital signature, using the values of `\u003cTrustStore\u003e` and `\u003cValidateSigner\u003e` as described above. If validation fails, then the policy will raise a fault.\n\nOnce the policy has completed without raising a fault, the developer of the proxy can be sure\nof the following:\n\n- The digital signature on the assertion is valid and was signed by a trusted CA\n- The assertion is valid for the current time period\n- The subject and issuer of the assertion will be extracted and set in flow variables. It is the responsibility of other policies to use these values for additional authentication, such as checking that the subject name is valid, or passing it to a target system for validation.\n\nOther policies, such as ExtractVariables, may be used to parse the raw XML of the assertion\nfor more complex validation.\n\n*** ** * ** ***\n\nFlow variables\n--------------\n\nThere are many pieces of information that may be specified in a SAML assertion. The SAML\nassertion itself is XML that can be parsed using the [ExtractVariables policy](/apigee/docs/api-platform/reference/policies/extract-variables-policy) and other\nmechanisms in order to implement more complex validations.\n\nError reference\n---------------\n\n\nThis section describes the fault codes and error messages that are returned\nand fault variables that are set by Apigee when this policy triggers an error.\nThis information is important to know if you are developing fault rules to\nhandle faults. To learn more, see [What you need to know\nabout policy errors](/apigee/docs/api-platform/fundamentals/what-you-need-know-about-policy-errors) and [Handling\nfaults](/apigee/docs/api-platform/fundamentals/fault-handling).\n\n### Deployment errors\n\nThese errors can occur when you deploy a proxy containing this policy.\n| **Tip:** Need help resolving an error? Click *build* in the Fix column for detailed troubleshooting information.\n\n### Fault variables\n\nThese variables are set when a runtime error occurs. For more information, see [What you need to know\nabout policy errors](/apigee/docs/api-platform/fundamentals/what-you-need-know-about-policy-errors).\n\n### Example error response\n\n**Note:** For error handling, the best practice is to trap the `errorcode` part of the error response. Do not rely on the text in the `faultstring`, because it could change. \n\n```transact-sql\n{\n \"fault\": {\n \"faultstring\": \"GenerateSAMLAssertion[GenSAMLAssert]: Invalid media type\",\n \"detail\": {\n \"errorcode\": \"steps.saml.generate.InvalidMediaTpe\"\n }\n }\n}\n```\n\n### Example fault rule\n\n```scdoc\n\u003cFaultRules\u003e\n \u003cFaultRule name=\"invalid_saml_rule\"\u003e\n \u003cStep\u003e\n \u003cName\u003einvalid-saml\u003c/Name\u003e\n \u003c/Step\u003e\n \u003cCondition\u003e(GenerateSAMLAssertion.failed = \"true\")\u003c/Condition\u003e\n \u003c/FaultRule\u003e\n\u003c/FaultRules\u003e\n```\n\n\u003cbr /\u003e\n\nRelated topics\n--------------\n\nExtracting variables: [Extract Variables\npolicy](/apigee/docs/api-platform/reference/policies/extract-variables-policy)"]]