We got this implemented so I'm going to mark it as answered. Maybe it will come in handy to someone trying to do similar things in the future. A couple other things I might mention.
1. First always consider these principles, quoted from CA support.
The key to this is the certificates assigned to having "Sign Certs" option in the Manage Certificates interface. During the SSL handshake the client will tell the gateway what TLS provider and cipher suites it can handle then the Gateway will align the TLS and pick the highest agreed upon Cipher. Also as part of this handshake it will ask for a Client certificate and provide a list of trusted CA certificates based on certificates tagged with the Sign Certs option (as seen above). The certificate in the list must be one of the issuer certificates used to sign the client certificate being used. If not then the client will not provide any certificate for validation. Additional note that unless the certificate is self-signed you cannot provide the client public certificate as part of this list.
If during implementation of client authorization through use of the “Require SSL or TLS Transport with Client Authentication” assertion the error encountered is “No client certificate was present in the request” and/or “Authentication Required”, there is most likely something wrong with the above described scenario.
2. For general client authentication configuration you might want to look at the doc for the OAuth Toolkit. The 'configure authentication' section of that document is using exactly this process, creating the FIP, etc.
3. Finally, we have a twist to this scenario where we want to collect the client's cert on one system and authorize it on another. Support provided a very handy outline for doing so that you might find helpful as it roughs in all the assertions necessary.
External policy obtains certificate and insert a base64 encoded version into the header:-
Require SSL or TLS Transport with Client Certificate Authentication
Request: Add Http Header mycert:${request.ssl.client Certifcate.base64}
Route via HTTPS to https://localhost:8443/429165/internal
Internal Policy decodes cert back to x509, then makes the gateway believe it obtained it from the request via the Retrieve Credentials from Context Variable assertion, before authenticated via normal process:-
Base 64 Decode ${request.http.headervalues.mycert} into ${mycert} as X.509 Certificate
Request: Retrieve Credentials from Context variable: ${mycert}
Request: Authenticate against Internal Identify Provider
Return Template Response to requestor