APM Cookbook: AutoLaunch SAML Resources
Introduction
After the SAML labs at Agility I got a lot of questions about how to automatically launch SAML resources and skip the webtop, and I promised I'd write it up for you. If you haven't been to Agility, check it out next year, it's a great event!
Let's say you have a virtual server available at idp.company.com with a webtop and SAML resources on it. Users are complaining that they have to login to the webtop and click the resource they want instead of automatically getting to what they wanted. Fortunately this is easy to solve!
There are two easy ways to automate this and improve your user's experience. In either solution below you'll add the iRule to the virtual server hosting the webtop. You can add additional lines for more matches right below the switch statement just like I've shown on the example. The part that starts with "/saml/idp/res?id=" is a reference to the SAML resource, so it will be the full SAML resource path after that. My example SAML Resource object is named "app1-saml-resource" and is under the default /Common partition. Yours may be under a different partition or iApp container so you can adjust the path accordingly.
URI Based Autolaunch iRule
This solution requires users to specify in the URI which resource they want. In this example, putting idp.company.com/app1 into the address bar will autolaunch the app1 SAML resource.
when ACCESS_POLICY_COMPLETED {
switch -glob [string tolower [ACCESS::session data get session.server.landinguri]] {
"/app1" {ACCESS::respond 302 Location "/saml/idp/res?id=/Common/app1-saml-resource"}
}
}
when ACCESS_ACL_ALLOWED {
switch -glob [string tolower [HTTP::uri]] {
"/app1" {ACCESS::respond 302 Location "/saml/idp/res?id=/Common/app1-saml-resource"}
}
}
Improvement: Hostname Redirects
This improvement enables the user to use an alternate hostname to reach the webtop VS and get redirected to the autolaunching URI. You'll need to have a wildcard or SAN certificate and you can CNAME the new hostname to your original one, idp.company.com. In this example, if the user reaches the webtop by going to app1.company.com then they will be redirected to https://idp.company.com/app1 and get autolaunch. You just add this code to the bottom of the other iRule or place in a separate iRule.
when HTTP_REQUEST {
switch -glob [string tolower [HTTP::host]] {
"app1.company.com" { HTTP::redirect "https://idp.company.com/app1" }
}
}
And that's it!
Published Aug 10, 2016
Version 1.0
Graham_Alderso1
Employee
EmployeeGraham_Alderso1Employee
Employee
Graham_Alderso1Juan,
You're in luck, that is already default behavior! In SP initiated the user is sent directly back to the SP with the assertion following policy completion (authentication), they do not see a webtop. It knows what SAML resource to use because it can match the incoming SP initiated authentication request up to the assigned SAML resources.
If you see a webtop when attempting SP initiated, but IdP initiated auth works when the user clicks the webtop link, then there is a misconfiguration at the SP. It's not the IdP configuration because it can successfully perform IdP initiated auth. The SP misconfiguration results in F5 not identifying the request as SP initiated authentication request, so it just shows the webtop. The most common cause is the SP is not redirecting the user to the correct URI (/saml/idp/profile/redirectorpost/sso) or the SAML AuthN request is malformed/not present.
juanNimbostratus
Hello. How does that irule handle the SP-Initiated case?. I mean, when the VS receives a SP initiated session (https://sss.sss.com/saml/idp/profile/redirectorpost/sso), how it knows what SAML resource to provide to that session?. Could it be launched without a webtop? Thank you!.
ClydeMuch appreciated, Graham!
- Graham_Alderso1
Yep, I haven't written an iRule that does this yet, but that's the first solution that comes to mind (assuming there's a good Referer header to key off) and you're going down the right path. You'd want to remove the session as well. https://clouddocs.f5.com/api/irules/ACCESS__session.html
 
Actually, in your case since you can control the redirect URL, maybe the simplest is to just choose something like /mycustomlogout and redirect them there, and then your iRule can just look for that instead of bothering with the Referer header.
 
Perhaps try this (untested).
 
when HTTP_REQUEST { if { [HTTP::uri] equals "/mycustomlogout"} { ACCESS::session remove HTTP::redirect "https://mywebsite.com" } } - Clyde
Thanks a bunch, Graham. The SP we are working with is able to redirect the user to another URL when they log out of the SP, so I will try just redirecting them to the hangup page in APM. I tested it (by spoofing the redirect) and seems to achieve what you stated. And yes, I am utilizing Kerberos to log the user in automatically, so that is exactly what is happening (/my.policy and logged back into the app).
 
For the iRule piece you are referencing, I assume one of the examples here is likely what I would need to do if I need to go that route.
 
[https://devcentral.f5.com/s/articles/irule-security-101-06-http-referer]
 
- Graham_Alderso1
If you setup SAML SLO (SAML Single LogOut) then it will log the user out of the APM. As an alternative, you can have the SAML SP send a logged out user to your apm with the URL https://myapmvirtualserver.ccompany.com/vdesk/hangup.php3 and the session will be terminated. Or you could just leave the APM session in place and redirect a logged out user to something else like your website.
If you have auto-login through something like NTLM or Kerberos, then when the user is logged out they may just get logged back in automatically depending on which method above is used, so in that case you might want to write an iRule that intercepts and redirects the user somewhere else after a logout or perhaps anytime the incoming referer header is the logout page of the app, that way they won't just go to /my.policy and then get sent along to the app again.
- Clyde
Graham, thanks for the helpful iRule. One thing I am seeing is that user logs out of the SP, they are also directed to my IDP to logout there. However, it appears the iRule gets hit again and they are just redirected back to the SP with the same SAML assertion. Hope that makes sense. Any ideas?
- Stéphane_PICARD
Clear, thanks!
- Graham_Alderso1
Stephane Picard,
This article won't provide any benefit for the Big-IP as SP use case, only Big-IP as IdP.
When Big-IP is acting as a service provider you just need attach to the application's virtual server an access profile with a SAML Auth object. That is where you configure it to act as a SAML SP and redirect to the IdP for authentication automatically with an SP initiated authentication request. It will also accept IdP initiated authentication automatically.
If you just want a link, you could link to however the IdP auto-initiates and IdP initiated authentication, or you could just link to the virtual server with your application and it will automatically start SP initiated authentication if your access profile is setup properly, nothing special needed.
- Stéphane_PICARD
Hi Graham and thanks for this interesting article. One question on my side if i may: does this article works only where F5 is IdentityProvider ? My use case here is to use F5 as Service Provider with Identity Provider being a third party. Both are linked though "SAML". Then my users need to access a web application but do not want to go through a webtop. I found a way (thanks to a Virtual Server dedicated to my "web application") but was wondering if your case could also be another way. Hope i am clear enough...
Maybe me understanding where do such link (/saml/idp/res?id=/Common/app1-saml-resource) comes from would help. Would i also be able to have such "SAML resource link" when F5 is Service Provider and not Identity Provider or it does not make sense ?
Thanks a lot