Design for APM SSO for external web sites without SAML

Setup DNS on internal network to resolve the hostnames for the external cloud apps to internal LTM VIPs.

 

You could do this in a few ways:

 

1. Static Host mapping
2. Real-time RESOLV:lookup (and cache responses)
3. Out-of-band process to periodically poll and update a local static entry

Configure LTM for each VIP to forward to the actual public web application hostname (via an irule to resolve and cache the IP addresses of the web app)

 

See above.

 

Insert APM authentication for each VIP with cross domain SSO to pass through corporate credentials to cloud based apps (i assume here there is authentication synchronization between the web app the APM Source)

 

I'm curious about this. The term "cross domain" is generally inclusive of auth protocols like Kerberos, which is something you couldn't do with remote cloud-based services. I'd venture that your options are probably limited to user/pass is some HTTP-based auth method like Form, Basic, or NTLM. In either case, there's SSO profiles for each.

 

Some of the web apps require a customer number to be submitted before the login page is displayed. I'm guessing i may need an irule to get past this page before i can pass the users credentials via SSO ?

 

This is even more curious. The SSO itself is going to look for some pattern (a form page, a specific URL, form parameters, some combination of these) to trigger posting credentials. That should be an issue. But the logic for sending the customer number could be a bit more complex. Is there a form that's returned from the remote server for the user to enter the customer number? Is it possible to include the customer number in a query string? However it actually works, you could potentially:

 

1. Create two SSO profiles and use iRule logic to switch between them based on some event (ie. a specific response perhaps)
2. Use an SSO profile for the user/pass stuff and use an iRule to manually post the customer number.

Thanks for the feedback.

 

You could do this in a few ways:

 

Static Host mapping Real-time RESOLV:lookup (and cache responses) Out-of-band process to periodically poll and update a local static entry

 

I'll look into these options.

 

I'm curious about this. The term "cross domain" is generally inclusive of auth protocols like Kerberos, which is something you couldn't do with remote cloud-based services. I'd venture that your options are probably limited to user/pass is some HTTP-based auth method like Form, Basic, or NTLM. In either case, there's SSO profiles for each.

 

Cross domain SSO in F5 APM terminology is being able to sign into multiple URLs using a single authentication to the APM.

 

This is even more curious. The SSO itself is going to look for some pattern (a form page, a specific URL, form parameters, some combination of these) to trigger posting credentials. That should be an issue. But the logic for sending the customer number could be a bit more complex. Is there a form that's returned from the remote server for the user to enter the customer number? Is it possible to include the customer number in a query string?

 

Pretty sure its as form. Not sure exactly how it works but i'll do some further digging. Can the APM do the following ?

 

1. User signs into F5 APM page
2. User is forwarded to the page\form to enter their customer ID which they manually do
3. after this it he logon page is presented and APM automatically fills in the username and password to log the user in

The order here is important as the SSO only needs to happens after the customer ID is successfully entered.

 

Thanks

 

Cross domain SSO in F5 APM terminology is being able to sign into multiple URLs using a single authentication to the APM.

 

Well, technically that wouldn't necessarily be "cross-domain". There's a "multi-domain" mode within APM that allows you to authentication once and access multiple access policy VIPs, which is a client function. Then there's SSO, which allows APM to use whatever credentials a user has provided to authentication to different back end systems. That could indeed be Kerberos across multiple trusted domains, but that's only one of many possibilities. In your case though, you have remote services that most certainly aren't accepting Kerberos tickets, so your SSO is most likely going to be posting HTTP-based credentials to their logon page (user/pass form, Basic, NTLM).

 

Pretty sure its as form. Not sure exactly how it works but i'll do some further digging. Can the APM do the following ?

 

This config dances dangerously close to a reverse proxy, which depending on your criteria and how many external sites the user must access through this VIP, can have some complexity. Is it a handful of sites? Does it need to be in a full forward (web) proxy configuration?

 

The order here is important as the SSO only needs to happens after the customer ID is successfully entered.

 

Actually it shouldn't technically matter. The Forms SSO config is going to be on the lookout for the data that you've defined to identify the logon page. Whenever the SSO sees that, it'll post the credentials as required. It shouldn't matter when that happens. Now, if you're implying that it MUST only happen in a specific order, then you'd have to take additional measures to enable/disable SSO based on that criteria.