Forum Discussion

Barny_Riches's avatar
Barny_Riches
Icon for Nimbostratus rankNimbostratus
Aug 18, 2016

How best to achieve SSO between APM policies of different types (portal and ltm+apm)?

We provide external access to a number of internal resources via APM in BIGIP (11.6.0). Some of these resources can only be presented to external users via webtop-based portal access whilst others only require authentication and load-balancing (ltm+apm).

 

We would like users to be able to switch between these resources without having to re-authenticate. I have read some discussions about providing SSO between different APM policies using Domain Cookies and also seen suggestions that involve using SAML.

 

I would prefer to use SAML if possible, as access to some resources is (AD) group dependent and by passing group membership attributes within a SAML assertion, it would presumably allow us to apply specific rules for webtop portal resources.

 

What I would like to know is whether this is possible. Can APM act as both SP and IdP, so that APM secured resources defined as Service Providers redirect users to an APM hosted IdP service which in turn performs authentication and sends an assertion back to the original calling policy?

 

If it is possible, could someone point me to a KB article or outline briefly, at a high-level, the workflow required to achieve this? If I am over-complicating the solution I am happy to consider any alternatives.

 

Many Thanks,

 

Barny

 

APM
saml
security
SSO

8 Replies

Sort By
  • Evan_Champion_1's avatar
    Evan_Champion_1
    Icon for Cirrus rankCirrus
    Aug 19, 2016

    We use SAML for this. APM can act as SP and IdP and we use it for this.

     

    The best way to setup is:

     

    • Your IdP is a single virtual server with an APM policy that authenticates the users as you wish and then assigns one SAML resource for each application (via Advanced Resource Assign).
    • Each application's SAML resource links to one F5 IdP, so you need to create one IdP per application. Although they are separate they will all have the same entity ID. This allows you to keep SSO between apps but specify different configurations per application; for example, you may want the user's password to be sent (encrypted) to the webtop for SSO to Citrix or apps with form-based auth, where the password should not be sent otherwise, or cloud applications may have specific requirements that are different from your internal apps.
    • Each IdP is bound to one SAML SP per application.
    • Each application VS has an access policy that contains a SAML Authentication step pointing to an individual SAML SP.

    Here is a link to F5 instructions for how to setup:

     

    https://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-authentication-single-sign-on-12-1-0/29.htmlunique_1485171297

     

    There is another way to setup where you have one F5 SAML IdP for all your applications however you will not want to do this because you won't have the flexibility suggested above to have different configurations on a per-application basis.

     

    I really like this setup because all the "intelligence" about authenticating a user is in the IdP and is not replicated in each SP. In the SP I just do authorisation i.e. is the already authenticated user allowed to use this application. That makes the application's APM policy very simple and generally speaking cookie-cutter; I just copy an existing application's policy and change the group I am authorising against.

     

    As a note, although the document I linked to references SAML artifacts, I couldn't get artifacts to work. This is not required and increases complexity/more moving parts. However it bothers me that I couldn't get it to work :-) so I would appreciate if anyone who has successfully deployed could give pointers.

     

    Evan

     

    • Barny_Riches's avatar
      Barny_Riches
      Icon for Nimbostratus rankNimbostratus
      Aug 19, 2016

      Evan,

       

      Thank you very much for taking the time to explain this.

       

      Knowing that it is not only possible but that you have implemented something similar is very encouraging. I completely agree with your take that by separating the core authentication steps to the IdP makes adding new applications a relatively standard procedure. This is what I am hoping to achieve.

       

      I have, using your high-level guide, now put together a skeleton configuration of sorts. I am struggling slightly on the last leg and this may be the nature of the application I am securing. The initial request connects and the client is redirected to the IdP server. Authentication is performed but the IdP service does not seem to redirect the client back to the SP. There may well be configuration errors that I have yet to spot, but could you confirm on a general note, that in your setup, it is possible to perform SP as well as IdP initiated authentication using this method? The errors that I am seeing suggest that I need to end the IdP policy with a webtop and SAML resource assignment rather than relying on SP redirection.

       

      Thanks again for your guidance,

       

      Barny

       

    • Evan_Champion_1's avatar
      Evan_Champion_1
      Icon for Cirrus rankCirrus
      Aug 20, 2016

      In the IdP's access policy you will need to assign a SAML resource for each application. This provides the linkage between the IdP access policy to the IdP SAML objects and bound SP objects. Once you do this you should find it all works fine, for both IdP and SP-initiated. We use SP-initiated.

       

      Adding a webtop is completely optional and I did not add one. We have a separate webtop portal that has the SAML apps as well as other apps and I thought it would be confusing that a user went to the IdP by accident and saw a webtop that looks very much like our portal with only a fraction of the expected apps.

       

      Evan

       

    • Walter_Kacynski's avatar
      Walter_Kacynski
      Icon for Cirrostratus rankCirrostratus
      Aug 23, 2016

      Does this setup cause a single user to have two access sessions created? One for the IdP and the other for SP?

       

  • Barny_Riches's avatar
    Barny_Riches
    Icon for Nimbostratus rankNimbostratus
    Aug 25, 2016

    Thanks again Evan,

     

    I have double-checked the advanced assignment step within the IdP policy and application specific SAML resources are definitely being assigned. However APM still insists that a "Webtop configuration is required" and same error is being logged "Logon denied due to validation error, Error Code: 3000 (No Webtop)"

     

    I'm beginning to think that it is a version specific issue. The 11.6.0 documentation differs from the 12.1.0 documentation that you linked.

     

    In 11.6.0 the relevant SAML instructions state:

     

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

     

    Configuration requirements to support IdP- and SP-initiated connections
... 
  An access policy that:
    Performs authentication
    Assigns SAML resources and full webtop

    However the stipulation for a 'full webtop' assignment does not appear in the 12.1.0 documentation. I am going to try an lab this on 12.1.0 to see whether I have any more success.

     

    Thanks again for your guidance,

     

    Barny

     

    • Evan_Champion_1's avatar
      Evan_Champion_1
      Icon for Cirrus rankCirrus
      Aug 26, 2016

      That could be it -- we are using 12.1.0. I would recommend 12.1.0 HF1 for other reasons anyway, as it fixed some of the bugs I found with SAML. HF1 fixes a further regression in 12.1.0 where a user going to 

      https://yourserver/path/to/content
      ends up redirected back to 
      https://yourserver/
      after authentication and not 
      https://yourserver/path/to/content
      . This can be worked around but given you are upgrading you are better to go to HF1.

    • Barny_Riches's avatar
      Barny_Riches
      Icon for Nimbostratus rankNimbostratus
      Sep 01, 2016

      I just wanted to confirm that the problems I experienced were version related and that migrating my trial configuration to 12.1.1 has resolved these.

       

      I now have a fully working proof-of-concept which permits both SP and IdP initiated authentication and seamless cross-policy access.

       

      Thank you very much for all your help in getting this working - I really appreciate your advice.

       

      With regards to your specific implementation, you mention that the only logic you include within the SP policy (post SAML auth) is a step to verify that the user has permission to access the application. Assuming you are using some sort of group membership (e.g. AD) to determine authorisation, do you check group attributes passed within the SAML assertion sent to the SP or is the SP policy able to access session variables instantiated by the IdP policy?