locked
Identity framework token verification RRS feed

  • Question

  • One of my clients is having a problem I'm trying to better understand.  We have an ASP.MVC 5 web application deployed there (been in production for 7ish years).  It uses ADFS for authentication (WS Federation) along with the Identity framework on the .net side. 

    First some quick context....

    The client shares the servers amongst multiple applications  and the server essentially has each app deployed in a folder off the default web site.

    this particular app is located as follows:  https://<base url>/applications/<name of folder>

    We're currently trying to move this application to a new set of servers including having it use a newer ADFS server.  Everything else stays the same - same folder structure same folder names, etc.

    We have the site running on the new servers including the newer ADFS server.  I can access it from outside of their corporate network and it works exactly as it should.  If I connect to their vpn before trying to access the site, it also works just fine for me (some of their folks have repeated this test and it works for them as well this way)


    Here's the actual problem:

    If a user tries the same test from inside the network, they are redirected to the ADFS login page and after entering their credentials, ADFS redirects the user's browser to POST to a route in our application.  The payload for this post is the saml payload from ADFS (I think this is a post for .net to verify the token is legit - only a guess though).  What is supposed to happen at this point is the post returns a 302 (chrome says 302 Found) and redirect the user to the landing page of our application.  What it actually does is to return a 302 (chrome says 302 Moved) and redirects the user to the SITE root instead of the application landing page.  At this point, if you try to change the url in the browser to the correct path it quickly redirects you right back to this incorrect url (it at least thinks you have a valid token and skips the ADFS login screen).

    In addition to that last redirect being different, the other thing which is different is the ip address for the site.  In both cases we're using the exact same url but  the internal dns is translating that into an internal ip address rather than the public one I use.

    so in summary it seems like the first part of the flow all the way through you've entered your credentials into an adfs login page and it authenticates you seem to work consistently in both cases.  It's that very next step where it sends an HTTP POST request with the SAML payload in the request body where it seems to go wrong.  That POST request in both cases goes to the same url in my application but I do not have a controller action in my site to handle a post to the url it's hitting.


    Friday, August 28, 2020 6:29 PM

Answers

All replies

  • Hi TravisWltrs,

    Thank you for posting here.

    I have moved the thread to 'Where is the forum for...?' forum to help you find the correct forum to go ask questions.

    The CLR Forum discuss and ask questions about .NET Framework Base Classes (BCL) such as Collections, I/O, Regigistry, Globalization, Reflection. Also discuss all the other Microsoft libraries that are built on or extend the .NET Framework.

    Thank you for your understanding.

    Best Regards,

    Xingyu Zhao


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, August 31, 2020 1:39 AM
  • I'd try asking for help over here.

    https://forums.asp.net/

    https://docs.microsoft.com/en-us/answers/topics/adfs.html

    https://forums.asp.net/1227.aspx

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.


    Monday, August 31, 2020 1:58 AM