Forum Discussion

GBurch's avatar
GBurch
Icon for Altostratus rankAltostratus
Jun 12, 2020

SP Initiated SAML Authentication stops at Webtop page

I'm trying to set up a new SAML connection with an external 3rd Party. I have one similar SAML connection set up and functioning with a different 3rd Party, but I can't see the difference between the two.

 

I visit the URL of the external website, the browser is redirected to the F5's ssoportal, but it stops at the Webtop page, rather than redirecting the browser back to the website. When I view the logs, I can see that the F5 initiates a session for the user on the /Common/SSO-Portal.vs Virtual Server, processes the SSOPortal.profile Access Profile, assigns all the SAML Resources (including the one I'm trying to use), but seems to stop there.

 

If I compare it to the logs from the workign SAML connection, I can see the next step is "Client initiated SSO config received in metadata."

 

I'm very new to SAML, so not sure where to start troubleshooting.

application delivery
BIG-IP Access Policy Manager (APM)
saml
webtop
  • GBurch's avatar
    GBurch
    Icon for Altostratus rankAltostratus
    Jun 16, 2020

    Here's the traffic I'm seeing from the browser's developer tools:

     

    1. I send an HTTP GET request to the external webpage, it responds with 302 FOUND which has a location header of https://<internal address of our F5>/saml/idp/profile/redirect/sls?SAMLRequest=<Long String of Characters>&RelayState=<What looks to be the encoded URL that I originally visited>
    2. There's another HTTP GET to the location header from above. This returns 302 MOVED TEMPORARILY, and includes SAMLRequest and RelayState as Query String Parameters.
    3. After this, it's just the traffic to load the Webtop page

     

    I pasted the value of the SAMLRequest Query String into the URL Decoder you posted above, but it doesn't change the string (it just looks like random characters). I tried it with the value of the RelayState Query String, which does decode some of the characters, but not all. I tried pasting both outputs in the SAML decoder you posted above, but it didn't return anything.

    • GBurch's avatar
      GBurch
      Icon for Altostratus rankAltostratus
      Jun 17, 2020

      I've managed to decode the SAMLRequest data by pasting it straight into the SAML Decode tool, rather than decoding the URL first.

      The desoced SAML response I get is:

      <?xml version="1.0" encoding="UTF-8" standalone="no"?>
<saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://[internal address of F5]/saml/idp/profile/redirect/sls" ID="_aff60f5600c35a9c6ba7c629056c96ea" IssueInstant="2020-06-17T10:07:09.436Z" Version="2.0">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://[FQDN of external website]</saml2:Issuer>
</saml2p:AuthnRequest>

      Is it the value of the <saml2:Issuer> tag I'm looking at? The FQDN of this matches the FQDN of the ACS URL configured on the F5 under Access -> Federation -> SAML Identity Provider -> External SP Connectors. However, the ACS URL has additional file path which is not present in the decoded XML above. Does this meet to match exactly, or is this enough for the F5 to match the request up with the correct SAML Resource?

      The URL from the decoded XML above does match the Entity ID listed on the SP Connector

  • youssef1's avatar
    youssef1
    Icon for Cumulonimbus rankCumulonimbus
    Jun 16, 2020

    Hello

    Yes modification take effetct immediately.

    As I explain you you can caputre SAML Request:

     

    To view a SAML response in Chrome

    1. Press F12 to start the developer console.
    2. Select the Network tab, and then select Preserve log.
    3. Reproduce the issue.
    4. Look for a SAML Post in the developer console pane. Select that row, and then view the Headers tab at the bottom. Look for the SAMLrequest attribute that contains the encoded request.
    5. decode URL (https://urldecoder.org)
    6. - Then decode saml (https://samltool.com/decode.php)

     

    It's the easier way to find the problem.

     

    Keep me in touch.

  • GBurch's avatar
    GBurch
    Icon for Altostratus rankAltostratus
    Jun 15, 2020

    Ah, I had wondered how it matched up the incoming SAML request with the SAML resources that have been configured.

     

    The 3rd party has confirmed what the ACS URL should be, the URL in the original metadata was incorrect. I've manually corrected it under Access -> Federation -> SAML Identity Provider -> External SP Connectors, and cleared off am my SAML sessions, but it's still getting the same result. Should the change have taken effect immediately?

  • youssef1's avatar
    youssef1
    Icon for Cumulonimbus rankCumulonimbus
    Jun 15, 2020

    very well I understood your deployment.

     

    so you have 2 saml ressources, for each saml resource it must have its own IDP bind to the SP.

    in your access profile you need to set SAML ressources in "Advanced ressource assign" (bot old and new one).

     

    did you test to connect directly on the idp URL and click on the resource directly on the webtop? it works?

     

    what I suspect is that you don't match the ACS URL in the saml request. let me explain.

    On the SSO/Auth Domain tab for that policy the "SSO Configuration" dropdown is set to "None", that means you don't have a default IDP.

    if you would have a default IDP and no SAML resources matched. you would have had a SAML error.

     

    so here is how you should proceed:

    - try to access SP and capture the saml request (F5: dev tools or fiddler)

    - decode URL (https://urldecoder.org)

    - Then decode saml (https://samltool.com/decode.php)

     

    in the saml request you will see the ACS URL, you must confirm that this is the one you configured in the external SP.

    I'm sure this is the problem ...

     

    Keep me in touch and tell me if you need more details. 

     

    regards

     

    • GBurch's avatar
      GBurch
      Icon for Altostratus rankAltostratus
      Jun 15, 2020

      Is it the URL in the <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"> field that I'm looking for? Which needs to match the ACS URL?

    • GBurch's avatar
      GBurch
      Icon for Altostratus rankAltostratus
      Jun 15, 2020

      Could you just clarify how I capture the SAML Request from the F5?

       

      Many thanks

  • GBurch's avatar
    GBurch
    Icon for Altostratus rankAltostratus
    Jun 12, 2020

    Hi Youssef,

     

    Thanks for the quick reply.

     

    I can confirm that under Access -> Federation -> SAML Resources, there is a resource configured for both the existing and the new connection I'm trying to set up.

     

    Under Access -> Federation -> SAML Identity Provider -> Local IdP Services, there is an entry for the new site, which is bound to the SP connector that was created by importing metadata from the 3rd Party

     

    I'm not sure I follow your last point, there is a 1:1 relationship between Local IdPs (under Access -> Federation -> SAML Identity Provider -> Local IdP Services) and External SPs (under Access -> Federation -> SAML Identity Provider -> External SP Connectors)

     

    Both SAML connections are using the same Access Profile (under Access -> Profiles / Policies -> Access Profiles) On the SSO/Auth Domain tab for that policy the "SSO Configuration" dropdown is set to "None". On the Access Policy tab for that profile, there is one Webtop listed (we only have one setup). Each of the new connections has their own Webtop Section associated with this policy, each section has the SAML Resource listed against it.

     

    I should have said in the original post, I can see the entry for the new site on the Webtop page when the browser stops there, it's just that I'd expect it to slently conduct the SAML authentication and redirect the browser back to the originating website.

  • youssef1's avatar
    youssef1
    Icon for Cumulonimbus rankCumulonimbus
    Jun 12, 2020

    Hi,

     

    Can you please confirm the following point:

    • do you use SAML ressources for the working sp and also for the new SP.
    • From (Access ›› Federation : SAML Identity Provider : Local IdP Services) you validate that you bind your new SP.
    • Your have only one IDP attached to your both External SP.

     

    Last point, click on your "Access profile name" go to tab SSO/ Auth Domains then validate that your IDP is correctly set on "SSO Configuration"

     

    regards