Forum Discussion
How do I determine SP origin on a BigIP IdP
Background:
We have a BigIP 14.1 environment, and we've set up an idp to respond to https://idp.domain.com, where only the IdP Entity ID differs, such as https://idp.domain.com/service1, https://idp.domain.com/service2 etc.
We also act as an SP for an external IdP, so the user has two AAA to choose from.
Some of the services are restricted to use only one of these, and we'd like to skip over the form where the user choose AAA to use for these. Together with an F5 consultant, we solved this by using an iRule listening to the event ACCESS_POLICY_AGENT_EVENT. In it, we scan for the Referer header in the session.server.initial_req_hdrs variable.
We then use a switch -glob statement to differentiate between the various origins, setting session.custom.ga_result to 0, 1 or 2 accordingly, meaning choice, local AD or external IdP.
This was the foundation left to us by the consultant, and it has since been refined by us.
Question:
The above solution works for the most part, but as we bind more SPs to the solution, we find that not everybody has the courtesy to provide a Referer header. Their solutions may not even make it possible. It has really been nagging me.
I have tried two things:
1) Receiving the session.bigip_idp_sp_info variable that contains the name of the SP connector. Except it's not set at the point of ACCESS_POLICY_AGENT_EVENT, so it's empty
2) I tried using the ACCESS_SAML_ASSERTION and extract the saml2:Issuer-attribute from the XML, but this event is triggered after ACCESS_POLICY_AGENT_EVENT, so I can't use that either.
I'm not a SAML expert, and I have to no avail asked several of our SPs for advice as I am certain this has to be solved in the SAML scope of things rather than with guesswork within an elaborate iRule.
How do sane people solve this?
Hi Samuel
How did you go with delv3chio's solution? Wish that was around 9 months ago ;)
We have an iLX plugin that inflates/parses the incoming SAML assertion. It grabs the issuer and/or the ACS url and we then make decisions in the policy based on the returned results.
Cheers,
Simon
- delv3chioEmployee
The best way I can think of to do this is to have each of the SPs send to their own SSO URL, branch these off in the VPE by landing URI, then re-assign the landing URI as 'return {/saml/idp/profile/redirectorpost/sso/}' before they hit the login page and it will maintain that SAMLRequest from the SP and continue on as SP initiated connections.
Otherwise, if you do not re-assign the landing URI, the BIG-IP will not recognize the connection as SP initiated, drop the SAMLRequest, and treat the connection as if it was IdP initiated.
I wrote this support solution:
Hope it helps!
- raZorTTCirrostratus
Hi Samuel
How did you go with delv3chio's solution? Wish that was around 9 months ago ;)
We have an iLX plugin that inflates/parses the incoming SAML assertion. It grabs the issuer and/or the ACS url and we then make decisions in the policy based on the returned results.
Cheers,
Simon
- Samuel_RydénAltocumulus
Hi,
Thank you, yes I ended up using an iLX plugin that inflates (when needed) and parses the incoming SAML assertion as well, based on some proof of concept I found somewhere. I then set a session variable and use it later in an iRule to determine which kind of IDP to send it off to.
The code is okay, but the approach seems a bit gritty to me. We run 16.1.3 nowadays and I don't actually know if this is still the best approach, or if some session variable is set behind the scenes nowadays, the idp set up has just worked since. 🙂
Sorry for the late response, I actually couldn't find back to the article after some changes. Only found back to the forums because somebody gave me Kudos. So thanks. 🙂
- Samuel_RydénAltocumulus
Is there nobody out there familiar with using a BigIP as an IdP who can identify anything we're doing wrong in our thinking or methodology in this scenario, or who has faced a similar problem?
- Samuel_RydénAltocumulus
Thank you!
I will try your approach as soon as I have a service window and I will report back to the community once it's done.
It looks very, very promising.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com