Forum Discussion

Barny_Riches's avatar
Barny_Riches
Icon for Nimbostratus rankNimbostratus
Nov 02, 2015

Applying client initiated form-based SSO actions to multiple Portal Access resources in APM 11.6

I am using BIG-IP APM 11.6.0.

 

I have a full web-top that is assigned to users via an APM Access Policy.

 

Remote users are assigned different, multiple, Portal Access resources depending on LDAP group membership.

 

These Portal Access objects point to internal web-based applications which are configured for full patching, allowing Big-IP APM to intermediate requests to these services.

 

I am struggling to understand the object level to which I need to apply client-initiated form-based SSO configuration such that when a user follows a web-top link to such a resource, SSO session username & password details are posted to the various, different login forms.

 

SSO profiles can be applied at Access Policy level and also at Portal Access list level, if a resource item is created.

 

I have followed the documentation in;

 

https://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-authentication-single-sign-on-11-6-0/23.htmlconceptid

 

... and I have also read most of the posts here on DevCentral that are in any way relevant.

 

e.g.

 

https://devcentral.f5.com/questions/sso-in-https-portal-access-resource-items https://devcentral.f5.com/questions/using-different-sso-methods-for-different-portal-applications-through-apm

 

I have tried adding SSO profiles to Portal resource items and to the Access Policy as well as combinations of one or the other. As far as I understand it, the SSO profiles determine whether the HTTP streams are monitored by the SSO agent and what determines a matching URI pattern required to trigger the form-based authentication.

 

I did manage to get SSO matches to work once for a single resource and by tailing the live APM logs I was able to see that the SSO agent was initialised and monitor match successes, but after editing profiles and playing around with assignment combinations this no longer works and I have not been able to re-produce this setup.

 

I don't think I have overlooked a conclusive answer here on DevCentral but I apologise if I have.

 

It would really help to have a simple high-level example of where the SSO profiles need to be assigned in 11.6.0 for such a scenario as the documentation is lacking in that area but implies that it is possible without the need to custom iRules.

 

All help/advice welcome.

 

4 Replies

  • Lucas_Thompson_'s avatar
    Lucas_Thompson_
    Historic F5 Account
    Basically, in the context of a user connection, zero or one SSO can be "selected". If you don't apply any to assigned Portal Access resource items (basically Allow ACLs that ALSO switch the SSO), then the default SSO for the Access Profile is selected. To complicate this a little more, there is also "multidomain SSO" that switches the selected SSO depending on the host header received from the client's browser. You can also switch the SSO manually if you want by using WEBSSO::select during the ACCESS_ACL_ALLOWED event. For Client-Initiated SSO, a few conditions must be met in order for it to insert the JS into the login page and do the auto-POST behavior: 1. The SSO must not be disabled from a previous unsuccessful logon attempt for the session (you would see something like "sso disabled for this session"). 2. The SSO must be selected to the correct one (this is visible in the logs). 3. The SSO must detect the correct URI in the web page (this is visible in the logs). 4. The SSO must detect the form (also in the logs) 5. There must be no JS errors that stop the browser from executing the injected JS (look for errors in the Dev Tools console in Chrome or FF).
  • Thanks for taking the time to reply.

     

    I think I understand the conditions you outline, however can I clarify the first part of your response?

     

    So, if an SSO profile is not assigned to a Portal resource item, which are essentialy ACLs, then a profile assigned to the Access Policy will be used. Does there need to be an SSO profile assigned to the Access Policy for SSO to work, or can you simply assign these to the resource items and leave the Access Policy SSO configuration set to none?

     

    Apart from the single occasion when I happened apon a working config combination, I don't see the SSO agent referenced in the logs. I believe that entries were prefixed with somthing like SSO v2 (or similar). On this occasion I could see the requested paths and entries when URI's used for form detection were matched. Since making changes, I now seem unable to trigger SSO at all.

     

    Is what I am trying to achieve possible?

     

    • user authenticates successfully
    • username & password are assigned to user SSO session vars
    • user follows webtop link to resource A
    • SSO profile attached to resource A detects SSO URI and using javascript inserts & posts session vars to login script
    • user follows webtop link to resource B
    • SSO profile attached to resource B detects different URI and posts session vars to resource B login script

    Apologies for all the questions, I am new to APM and I've been at a dead-end with this for many days.

     

    • Ryan77777's avatar
      Ryan77777
      Icon for Altocumulus rankAltocumulus

      I'm facing a very similar situation. What is super aggravating is that I have SSO configured, but it never does anything when launching a portal access link from within the webtop. It's a very simple form-based authentication mechanism. And there is nothing logged to syslog or /var/log/apm so I have no idea what is going on. Trying to troubleshoot that is ridiculous because there's nothing to go on. I don't even know if what I am doing is right! These guys are about to have to type in their passwords twice because I'm done! Hah...

       

    • Barny_Riches's avatar
      Barny_Riches
      Icon for Nimbostratus rankNimbostratus

      It wasn't easy and joining the dots between each component, understanding how they interact and what is going on at a low-level (especially with the SSO agent) proved challenging but I did get my solution working for most of the portal apps that I present to users.

       

      If you simply need to send the user's credentials to a web application then a simple SSO Configurations > Forms object would probably suffice.

       

      You would only need to use the Forms - Client Initiated object if the previous method fails to work. The reasons for this are commonly application security related - the application sets cookies and context which prevents direct authentication.

       

      If this is the case then you need to resort to the Forms - Client Initiated method.

       

      The first thing you need to do is increase logging. If you are using a more recent release, the logging is enabled in the General Settings of the the SSO object itself.

       

      After you have created your SSO Configurations > Forms - Client Initiated - set the Log Level to Informational or Debug.

       

      Now break your troubleshooting into two parts:

       

      1. detect the logon 'page'
      2. identify the logon form within the 'page'

      You will see in the logs something like "SSOv2 MATCH" (happy to be corrected) if the login page is detected. I most commonly detect this via the URI of the HTTP stream being sent from the backend resource.

       

      If the logon page is not detected then everything else is futile.

       

      Once the page has been detected, identify the form. For most simple forms you can simply use the Form Paramaters to identify the form. These are defined anyway as this is where you map local APM variables to the resource's form variables. Failing that try to use a the ID element if this is unique.

       

      Once you have successfully identified the form, the SSOv2 agent should match the login page, identify the form and using some hidden javascript sent to the client browser, autosubmit the relevant values to the backend system.

       

      Again - if the logon form is not detected, then the SSO agent will not be triggered and nothing else will happen. Detection is where most of my problems lay. I still have one problem app that loads the authentication form client-side after the DOM has loaded and is not detectable by APM within the HTTP stream, but for the most part I have been able to detect and identify the form eventually.

       

      One final thing to point out. APM substitutes internal tokens for SSO credentials as they are sent to the client browsers. These are then replaced with stored variables as the form passes back through BIG-IP en-route to the backend server. This ensure that the information is secure as you don't want something like a password sitting in clear-text in a web-page cache.