APM Cookbook: SAML IdP Chaining
As an APM subject mater expert at F5 I often find myself in situations where a customer or colleague needs an example of a particular configuration. While most of these requests are easily handled with a call or WebEx I'm a firm believer in sharing knowledge through documentation.. and I don't like getting calls at 3 AM.
If you're like me you grew up with the O'Reilly Cookbook series which served as a great reference document for various development or server configuration tasks. My goal is to create a similar reference resource here on DevCentral for those one-off scenarios where a visual example may help your complete your task.
For the first APM Cookbook series I'll discuss SAML IdP chaining.
Overview
Security Assertion Markup Language, more commonly known as SAML, is a popular federated authentication method that provides web based single sign-on. One of the key security advantages to SAML is the reduction in username/password combinations that a user has remember... or in my experience as a security engineer the number of passwords written on a post-it note stuck to their monitor.
There are two major services in a SAML environment:
- IdP - Identity Provider
- SP - Service Provider
The identity provider is the SAML service that authenticates the user and passes an assertion to then service providers proving the user's identity. F5's APM performs both IdP and SP services and allows customers to easily deploy federated authentication in their environment.
In more complex scenarios you may run across a requirement where multiple SAML IdPs need to be chained together. This comes up from time to time when customers have contractors that utilize federated authentication for authorization to corporate resources.
Example
For our configuration we have the Globex Corporation that uses APM to authenticate uses to Office 365. Globex hire contractors from Acme Corp. who authenticate using the Acme Corp. ADFS environment. However, since Office 365 is configured to authenticate against the Globex APM we need to convert the Acme Corp. SAML assertion into a Globex SAML assertion, which is known as IdP chaining. The step ladder for this process is shown below:
1. User requests https://outlook.com/globex.com
2 - 3. Office 365 redirects user to idp.globex.com
3 - 4. idp.globex.com determines user is a contractor and redirect user to sts.acme.com
5 - 8. User authenticates using Acme credentials and is then redirect back to idp.globex.com
9. idp.globex.com consumes the Acme SAML assertion and creates a Globex SAML assertion
10. User is redirected back to Office 365
11 - 12. Office 365 consumes the Globex SAML assertion and displays the user's mail
Configuration
To configure your APM SAML IdP to accept incoming assertion from sts.acme.com we need to create an external SP connector.
Under the Access Policy -> SAML -> BIG-IP as SP configuration section:
1. Create a new SAML SP Service
2. Export the SP metadata and configure sts.acme.com accordingly (follow your IdP vendor's documentation)
3. Click the External IdP Connectors menu at the top
4. Click the dropdown arrow on the create button and choose From Metadata (import the metadata from sts.acme.com)
5. Bind the Local SP service to the external IdP connector
Now that idp.globex.com and sts.acme.com are configured to trust one another we need to configure the APM IdP to consume the sts.acme.com SAML assertion. The IdP's Visual Policy Editor should look similar to the image below:
1. The Decision Box asks the user what company they're with. This is a simple example but more elaborate home realm discovery techniques can be used.
2. The SAML Auth box is configured to consume the sts.acme.com assertion
3. Since we no longer have a login form on the IdP we need to set a few APM session variables:
- session.logon.last.username = Session Variable session.saml.last.identity
- session.logon.last.logonname = Session Variable session.saml.last.identity
4. Create an Advanced Resource Assign that matches your existing IdP Advance Resource Assign.
Conclusion
This particular post was a little longwinded due to the steps required but overall is a fairly simple configuration. So the next time someone asks if your F5 can do IdP chaining you can confidently reply "Yes and I know how to do that".
- Great article, it really works :) Please note the single logout request is not propagated to the chained IdP. However - first things first, IdP chaining is a nice feature..
- MicaelC_243041Nimbostratus
How to get the SLO to work in this scenario? I'm running this in v12, and everything works except for SLO. I am unable to terminate the session at the external IDP so any returning user is automatically authenticated even if they clicked the logout button in the application.
I've tried using irules etc, but they only terminate the local session, not the session at the IDP level. Even try creating my own SLO request to the IDP, but so far unsuccessfully.
/M
- MarvinCirrocumulus
I have the same issue here one IDP session is terminated but the other one remains active because the SLO is not send through, were you able to fix this issue?
- MarvinCirrocumulus
just for your information I got the SLO to propogate to the external IDP and close both IDP sessions and also send the SLO response back to the SP with some Irule magic
- Peter_BaumannCirrostratus
Hi
Very nice! Do you have an example of this iRule you used to solve this SLO problem?
I'm very interested in it.
Thanks,
Peter
- MarvinCirrocumulus
Hi Peter yes sure I can show you the Irule but it basically redirects the /saml/idp/profile/post/sls to the IDP (in my case it is also the F5 but you could send it to the external IDP) and then when you receive the reply then you let the SAML SLO process. In the irule you use ACCESS::restrict_irule_events disable to overrule APM decision making so it will get redirected before APM handles the SLO and then when we receive the reply you can type return so APM will process it and reply to the SLO towards the external APP.
One thing this whole Irule customization to have SLO propageted properly with layered IDP setup worked great in version 13.1 however now we have 15.1 and it does not work properly (root cause unknown) however I found that in version 15.1 SLO is now propagated accross all layered IDP so we have it now working without the customized Irule solution. There is no documented change in behavior between 13.1 and 15.1 regarding SLO but I can assure you that it works now by default and that is what we all want right ;-)
If you still want to see the irule let me know I would recommend to try it with version 15.1