I agree somewhat with Edward that SAML tokens in the HTTP header can be risky. That being said, assuming a lot of details are not carried by the token it should be fine. Is it just an AuthN statement? Or is there expected to be a considerable amount of attribute statements as well? Attribute statements are what typically bloat out a SAML token to make it prohibitive for use in Headers. There is technically no limit on the HTTP header size imposed by the spec, but rather the server defines the limit. The default in Apache is 8k. That includes ALL header information, so cookies, etc, must be considered. I just created what I would consider the minimum in a SAML token for federating an identity (AuthN, Name Identifier, signed token) and it is about 3k. Bloat in XML can grow that rapidly with attributes, etc, but there should be room.
WRT providing an example, I'm not aware of any. I just worked through your use case and it is pretty straight forward. Here are some tips:
1. SAML is typically used as a form of Federation in this case - i.e. user is authenticated in one domain and sent to the next. The enforcement endpoint is merely confirming that the issuer is trusted. So you will need some endpoint to issue the token. Note that the Gateway can act as the issuer, so in Policy, you can check if the token is present and validate it *or* you can challenge for credentials and issue the token as part of the response. I think that is beyond the scope of this discussion, though.
2. You should ALWAYS use signed SAML tokens and have the certificate of the issuer installed in the Gateway. The issuer has the relationship with the LDAP, not the Gateway, unless, of course, the Gateway is the issuer. Whatever the case, you will need to import the signing certificate from the SAML authority (issuer), ensuring that the "Sign SAML Tokens" option is checked (and probably the Certificate is a Trust Anchor unless you are validating up a chain), then use that certificate as the basis for a FIP (Federated Identity Provider).
3. The (Non-SOAP) Validate SAML Token is the assertion you want to use to check the Authentication Statement. First, you must cast the token from the header to an text/xml message-type context variable, then call the (Non-SOAP) Validate SAML Token assertion with the various parameters you need to enforce (SAML Version, Authentication Methods, Subject Confirmation [which is probably Bearer], Name Identifier, and check the Required Embedded Signature box). This will automatically extract the credentials to the message context of the SAML token. Next just authenticate the SAML Token message against the FIP.
Here's a snippet of policy to illustrate the enforcement part:
Remember that the relationship with the LDAP is at the *issuer*, not the *enforcer*.
Hopefully, that helps to clear things up for you.
BTW, if you are concerned with bloat in the header you can always consider using signed JWT as the token format. They are much leaner and can do the same thing.
Also, if you do have Attributes in the SAML token that you need, you must call an additional (Non-SOAP) Validate SAML Token assertion that is for attributes. Unfortunately we can't do both Authentication and Attributes in a single call.