Forum Discussion
Separate Access Profiles for Different URIs on the Same Domain
Hello DevCentral, long time lurker, first time caller. Let me preface this post with the fact that I am not an F5 wizard, and I am learning a lot of what I am doing as I go (and thanks to the wonderful people of this community that ask and answer most of my questions before I have them).
I am working on moving some configuration from a legacy (non-F5) device to F5 APM+LTM, and am running into an issue with one pesky thing.
On the legacy device, we have a number of resources defined by their URI, with authentication defined on a per-URI basis. For example:
is protected by SAML authentication with a non-F5 IDP
is protected by Basic authentication authenticating against an on-prem LDAP
This is a configuration that I need to maintain as I move forward with porting the authentication in front of these apps to the F5. I found this post: https://devcentral.f5.com/questions/initiating-access-policy-from-irules which explains how to set up a VIP to virtually route traffic between two other VIPs that have different access profiles applied, and that portion of the configuration is working. I am able to hit , and I am redirected via my.policy and F5Networks-SSO-Req to our SAML IDP to sign in via our standard login page, and if I hit , I am prompted for Basic Auth (I am using the clientless mode iRule from https://devcentral.f5.com/questions/clientless-mode-and-401-for-poor-client-48409 to do basic auth without redirecting, as app2 needs to be accessed by some cantankerous old application that cant handle a redirect before auth). Both of these forms of authentication work independently just fine.
The problem I am encountering is when I try to move from app to app. Specifically, if I sign into the basic auth at app2, and then navigate to app1, I am redirected properly to our SAML identity provider, and after sign in, I am redirected back to the application that I requested, but APM does not seem to be aware that I have just authenticated, as it then redirects the request for the application back to the F5Networks-SSO-Req page, which then redirects to my SAML IDP, which then redirects to F5Networks-SSO-Resp, which then redirects to app1, and then repeats this process forever. As far as I can tell, the SAML request and response are both fine, and my relay state is being preserved (based on the fact that I am redirected to app1 in each iteration of the loop). In the logs, it appears that a session is established, and then immediately deleted each time I go through the loop. The only other thing that I can see that might be relevant in the logs is that on my initial request for app1 after signing into the basic auth at app2, the following is written to the logs: /Common/SAML_Auth:Common:ed7b1530 Session invalidated due to profile scope mismatch (expected '/Common/SAML_Auth', got '/Common/Basic_Auth'). This message only appears after the first request, and it does not actually invalidate the session (as I can navigate back to app2 and it does not prompt me for authentication again).
Looking for any ideas from anyone who has configured something like this before. I am willing to fundamentally alter how I am approaching the goal of having differing access policies per URI as well.
Thanks for any help
- John_Huttley
Employee
Hi,
On the all Access policies involved, have you enabled profile scope "Global"?
This setting prevents a malicious user from establishing a session using one virtual server, and then using that same session to access, potentially without further authentication, another virtual server and the resources behind it.
Profile Gives a user access only to resources that are behind the same access profile. This is the default value. Virtual Server Gives a user access only to resources that are behind the same virtual server. Global Gives a user access to resources behind any access profile that has global scope
This might be a quick fix by allowing authorisation to be shared, otherwise it will need a fair bit of plotting out and debugging..
John
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