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.
Are you just going to https://idp.company.com rather than https://idp.company.com/app1? This iRule redirects based on what URI was requested so that you could have multiple options here, so /app1 goes to app1, /app2 could go to app2, etc. You can make an app the default result by using / as one of the options as you have.
It's important then to realize that users will never be able to get to the webtop which might be a problem if you have multiple SAML resources there. If you only have the one, then it makes perfect sense to do that.
And if you only have the one SAML app and don't need multiple options you can remove the switch statement entirely and just do the redirect in the two events (the when statements). Something like this.
 
when ACCESS_POLICY_COMPLETED {
ACCESS::respond 302 Location "/saml/idp/res?id=/Common/app1-saml-resource"
}
when ACCESS_ACL_ALLOWED {
ACCESS::respond 302 Location "/saml/idp/res?id=/Common/app1-saml-resource"
}
Thanks for the reply Graham. Currently we only have the one, but there is a potential that we might use the F5 for more SAML connections in the future so I would like to leave it with the multiple options.
We are currently just using idp.company.com insteady of idp.company.com/app1. What would I need to change to use the /app1 model? As I mentioned above I would prefer to use that method in case we do use the F5 for multiple SAML resources.
You would change it to /app1 instead of / and have users type idp.company.com/app1 into their browser instead of just idp.company.com. It just keys off the URI match. You can even have both options listed and doing the same thing, that way if they forget the /app1 it will still work for now, but then later when you deploy more SAML apps you would remove the / option so that they get the webtop and can choose what SAML app if they don't select one by URI entry.
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 ?
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.
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?
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.
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.
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"
}
}
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!.
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.
I haven't done much research about this yet but here is what I will be looking into:
Use APM as SP and IDP => replace ADFS/WAP Proxy.
so configure an sp and and idp on the same bigip and bind them.
create two policies (sp policy and idp policy);
have two web apps webapp1.domain.com and webapp2.domain.com directed to the sp VS. no webtops no ressources.
user puts webapp1.domain.com in his browser and hits the sp vs .
sp vs redirects the to idp vs to do ldap auth.
idp vs redirectes to the sp vs (webapp2.domain.com) with saml assertion.
sp vs policy gets the username drom the saml assertion and does kerberos sso to webapp2.domain.com.
Is this possible with APM version 12 ?
I have already used APM as IDP with adfs and web application proxy to do kcd auth. but I want to get rid of adfs and webapplication proxy.
You should probably pick one of the DNS names to be the one used by the SP in its SAML configuration (webapp1.domain.com or webapp2.domain.com). So no matter what name is used to get to the SP, the one you picked in the SAML config is the one the user will be returned to after auth at the IdP. An alternative option if you must have the user returned to the same DNS name is that you could detect the DNS name, branch in the APM config, and have a different SAML Auth object for each DNS name (and related config).
You'll want to reference the manual for APM as SP and APM as IdP specific to the version you run. There are two ways to deploy APM as IdP, with webtop and one without. With webtop is required if you'll have multiple SPs, but not if you will only have one and want to limit it to ONLY SP initiated auth (meaning you can't go to the IdP first). The article above is about how to deploy with webtop, but have the SAML object autolaunch so the user doesn't see the webtop, which is different.
Note that it shows client cert auth on the client side and you're using SAML instead, but the setup of the Kerberos Constrained Delegation is the same.
If you need to seek more help, I suggest opening a new thread since this is out of scope for the article above and won't get the same level of notice/attention.
thanks Graham.
I have an sp/idp config to play with now but I'm not getting the expected result.
I will start another thread about this configuration.
I will need several web applications using the same idp.
OK, then you'll need to deploy the webtop and resources since you'll bind to multiple SPs. Fortunately when you use SP initiated auth as you described (user starts by going directly to the SP and it redirects), they won't see the webtop at the IdP anyway, it just automatically sends them back to the SP after auth. They only see the webtop if they start by going to the IdP. This article shows how to make the user not see the webtop even if they go directly to the IdP, which might be useful, but probably not in your circumstance.
I got that. I did some tests.
1 SP => VS + policy: Saml Auth (idp) => variable assign (saml attribute to username) => sso kerberos
1 Idp => VS+ Policy: logon page => Allow.
This ends in a saml/idp/profile/redirectorpost/sso error page.
I added a saml ressource and this ends in a policy deny page.
I understand the saml ressource is required but I don't see the link between the saml ressource and my web app. I didn't configure a portal or a webtop. I expect the redirect to my webapp after the saml auth (dp) step.
I have already used apm as idp with adfs without issues. I do use apm with sun ldap to ms kerberos without issues.
I guess I'm missing the saml ressource config/role here. I'll have to dig a little deeper in the config manual.
ok got it working with a saml ressource.
SP VS is mywebapp1.domain.com.
Simplest way is to create a second SP with a second VS for mywebapp2.domain.com
both SPs can be linked to the same IDP.
OR
use a portal and webtops.
Or
Do some voodoo in the SP apm policy to manage all the web app hostnames...
If I understood correctly this SAML IDP initiated solution provides SSO access to all external SAML resources with only a Single Login on the F5 IDP (IDP initiated), without having to login and authenticate to each SP (and F5 IDP) separately?
Technically this use case scenario would only work with IDP initiated combined with SAML resources and not with SP initiated SAML (no webtop and no SAML resources)? Is it possible to automatically send SAML responses to all the Service Providers with a single SP initiated login as well? Something similar to the Single Log Out (SLO) but then logging in for SP initiated SAML requests is that feasible in your opinion?
But again my guts tell me that the only solution that would fit this use case is IDP initiated, correct?
ps: perhaps the oauth integration delivers more flexibility with oauth bearer but I will have to do some labs at Agility 2019 to practice on this 😉
Marvin, when doing SP initiated, the auth request already identifies what app to redirect the user to and that happens natively, so the solution is not relevant for SP initiated problems.
As for your question about automatically sending SAML responses to every SP upon an SP initiated auth to any one of them (or for that matter, upon launching the webtop for IdP initiated), it's not something most environments would want but you may have a good use case. Theoretically it's possible, you could use this as example code to start from, and you'd have to make sure you launch a new tab for every one of those SPs. It would be definitely solving a different problem than this code, so I'd suggest that this work should happen/be published under a new article. If you take it on, be sure to comment back here linking to your new article so we can see the great solution! As you build that solution, remember that when publishing apps on a webtop for IdP initiated, SP initiated also automatically works in that same deployment.
Did an update cause this to stop working? I used this a while back to link directly to SAML resouces with mixed results. Back buttons on browsers would cause weird behavior (sometimes going back inside the remote application as expected, sometimes going back to the APM logon screen, sometimes to an error from APM). The project that prompted us to try the iRule fizzled out for a while, but it has just picked up steam again. Now when I try to use one of these resources directly from the links created, i end up on a "vdesk/hangup.php3" logout screen. APM logs show an authorization failure for the SAML resource. That SAML resource is assigned to my user in the APM Policy for the webtop with which it is associated. If I log on to the webtop, i can click the link there and it works like a champ. Immediately after the SAML resource auth failure in the APM logs is a "user logout request", which I assume is the reason for the hangup screen. I would call support, but they pointed out on a previous call (i was using CamElCaSe on a string that had been lower-cased... duh) that they wouldn't be able to provide support on a user created script... If it is still working for others, we may have something gone a little sideways in APM that needs other attention, but I'm not seeing odd behavior with anything else.
