For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Jason_Wilson_13's avatar
Jason_Wilson_13
Icon for Nimbostratus rankNimbostratus
Nov 18, 2013

Using different SSO methods for different portal applications through APM

Hi All,

 

Have an existing APM policy with a Portal application that is accessed through a Webtop. This application is integrated to AD and the F5 is correctly collecting credentials and forwarding through Basic headers to the backend application.

 

I now have a second application that uses a different set of credentials (not integrated with AD). When I have created the new application as Portal and try to access the application it is posting the SSO credentials of the other application (and failing).

 

There seems to be many places to configure SSO and I am getting a bit confused as to which does what.

 

In the Access Profile -> SSO/Auth Domains you select a SSO Configuration (which is the original Basic one). Then in Visual Policy Editor I have a pipeline step of SSO Credential Mapping - to extract from Logon Page and stick into Basic headers. Finally in Access Profile -> Portal Access: Portal Access List for the backend application there is SSO Configuration - which is set to None. This all works fine.

 

Now I add a new Portal Access resource and a new Portal Access List and try setting SSO Configuration to None (as I actually want no SSO for this second site). This was in the hope it would ignore the existing SSO of Basic.

 

This did not work, so tried created a Form based SSO with nothing in it and assign to the Portal Access List - this does not seem to make a difference.

 

So - what/when/why is this extra SSO Configuration used - I had hope it was to override a default.

 

Is there another way to allow two different types of SSO (well actually the second one is 'none')?

 

Thanks, Jason

 

2 Replies

  • There's actually a couple of ways to do this:

     

    1. The prescribed way is to add the SSO profile to the portal resource itself, and not to the access policy. I have issues with this one from time to time, so I tend to prefer the next option.

       

    2. You can point the Application URI field of a portal resource configuration to another (internal) VIP and then apply the access policy and SSO profile there. This is a type of "VIP targeting", but is actually a bit cooler because:

       

      • The session variables created in the outer portal policy are available to all of the inner policies, and
      • It makes your outer portal policy a lot cleaner.

    It also makes for a few more VIPs, but the internal VIPs can be in internal address space and on ports not allowed through your firewall. The only other significant caveat to this method is that you can't really do anything inside the individual internal access policies, so if you have multiple portal resources with their own SSO configs, and potentially different credential information, you need to create all of these session variables in the outer policy and reference them from the internal SSO profiles.

     

    There are actually a few other ways to do this stuff as well, but the above options are probably the easiest.

     

  • Found this thread as had an issue where we have SSO set on a Portal Access platform where one application (which uses different authentication) kept popping up logon screens when SSO was applied and thus we wanted to disable SSO on that app only.

     

    As the OP said that the alternative SSO he wants is "none" thats basically what I wanted.

     

    What I did was write an iRule to catch the specific URL of that application and then disable SSO as a result.

     

    Code below (as an example the app in question has url of http://host/nonssoapp😞

     

    when HTTP_REQUEST {
        if { ( [string tolower [HTTP::uri]] contains "nonssoapp" ) } {
            WEBSSO::disable
        }
    }

    Posting in case it helps someone else....