SSO/SAML 302 Redirect to Clients after Successful APM Login and Need to Source with FW Hide NAT Public IP

Can you elaborate a bit more? You mentioned SAML, so assuming APM is the IdP and the 3rd party is the SP, and perhaps you're doing IdP-initiated authentication (client goes to IdP first)? The only way to modify the source is to have the traffic to the 3rd party flow through the F5 (ie. load balance it). That would require some manipulation of response headers and other URLs to force the 3rd party traffic through an LTM VIP.

Gotcha, so normally the client would follow this link directly to the SP and arrive with its own ISP-derived source address. And the 3rd party isn't allowing this?? It's a little nuts I suppose, but again the only way to alter the source address going to the 3rd party is to force the client to go through the LTM to get to the 3rd party. Depending on the application on the other side that could be somewhat easy or very very very very (did I say very?) difficult. The first thing I'd try is doing some simple load balancing to the 3rd party through an LTM VIP - create a pool that points to the 3rd party, a VIP that binds the pool, and set your local Hosts file to point their URL at your VIP address. If that works, then the rest might not be so bad.

Maybe there is a better way to setup the SSO,SAML to 3rd party then I have used.

There's no version of the SAML protocol that I'm aware of that doesn't require the client to communicate directly with both parties. But then this isn't really a SAML problem. The 3rd party doesn't appear to allow the client to communicate with it directly, which is frankly somewhat counter intuitive.

I tried something similar. * ADFS (IdP) inhouse available via F5 https://adfshost/adfs/ls - ClientSSL and ServerSSL * Webapp (SP) inhouse available via F5 at https://website/* - SSLOffload (clientssl only) User should not be redirected to https://adfshost/adfs/ls but stay on https://website to perform Formbased Auth. It's similar to your "problem" you want the user to reach the IdP through your own Namespace(website). As long the IdP URI is unique and not used at your website you could use a stream profile and configure server-ssl profile (not required by website Pool?) and apply a iRule like this:

when HTTP_REQUEST {
     Make AD FS IdP available under Web Applications Hostname
     requires that IdP URI is unique and not used by the Web Application itself

     Disable the stream filter for all requests
    STREAM::disable

     LTM does not uncompress response content, so if the server has compression enabled
     and it cannot be disabled on the server, we can prevent the server from 
     sending a compressed response by removing the compression offerings from the client
    HTTP::header remove "Accept-Encoding"

    requires assigned server-ssl profile - will be disabled for regular traffic (Offload Site)
    if { [string tolower [HTTP::uri]] starts_with "/adfs" } {
        HTTP::header replace Host ""
        pool /Common/adfspool-443
    } else {
        SSL::disable serverside
        pool /Common/webpool-80
    }
}

when HTTP_RESPONSE {
    Check if response type is text
   if {[HTTP::header value Content-Type] contains "text"}
   {
        STREAM::expression "@https:///adfs@https:///adfs@"
         Enable the stream filter for this response only
        STREAM::enable
   }
}

some lines went wrong in the initial post

HTTP::header replace Host "adfshostname"

STREAM::expression "@https://adfshostname/adfs@https://webhostname/adfs@"