locked
Two questions about Web Application Proxy RRS feed

  • Question

  • Hi, all,

    For WAP, I have two questions about which I could not find a clear answer even after going through a lot of Microsoft Technet articles.

    First let's imagine a lab scenario - there are two claim-aware applications,  webapp1 is located in the company internal network, while webapp2 is Internet facing and located in the perimeter network, and for sure there are ADFS and WAP. The objective is to keep both webapp1 and webapp2 accessible to Internet users.

     

    Question 1:  Webapp2's integration with ADFS via the WAP. Does webapp2 server need to trust the ADFS server's token-signing certificate ( which is commonly self-issued)? In other words, does the WAP forward the  token signed by the ADFS server to the client as is, or the WAP decrypts the token and re-sign the token with its server certificate( in this case, the webapp2 server just needs to trust the WAP's server certificate)?

    Question 2: Publishing webapp1 to Internet users using ADFS preauthentication. Referring to https://technet.microsoft.com/en-us/library/cc732016(v=ws.11).aspx, it is written " 2. The web browser sends an HTTPS request to the Web Application Proxy server which redirects the request to the AD FS server." Since the ADFS server is not directly reachable to the client, how does  "Redirect" here work? Or does it mean the WAP terminates the HTTPS connection from the client and initiate its own HTTPS connection to the ADFS server just like what it does for webapp2?

    Looking forward to valuable answers. 

    Thanks.

    Monday, December 4, 2017 2:32 PM

Answers

  • Hi!

    Only ADFS signs the tokens- the WAP server never has the token signing cert and isn't trusted to sign tokens.

    In your Q1, webapp2 would be a Relying Party to ADFS, trusting the token signing cert/key. In the traditional passive flow scenario, the user's browser communicates with webapp2, which redirects the browser to sts.contoso.com (the ADFS). sts.contoso.com from externally, points to WAP. WAP terminates the request, proxies the request to ADFS and requests a token. The token is then given to the browser/user, who then returns to webapp2.

    in your Q2, the flow is user@browser -> WAP -> ADFS, where WAP terminates the communication/traffic and requests the token in the name of the user from ADFS.

    Thanks,Florian


    The views and opinions expressed in my postings do NOT necessarily correlate with the ones of my friends, family or my employer. Let's give the thread opener a chance to mark an answer themselves.

    • Marked as answer by Fisher W Tuesday, December 5, 2017 1:09 AM
    Monday, December 4, 2017 7:43 PM

All replies

  • Hi!

    Only ADFS signs the tokens- the WAP server never has the token signing cert and isn't trusted to sign tokens.

    In your Q1, webapp2 would be a Relying Party to ADFS, trusting the token signing cert/key. In the traditional passive flow scenario, the user's browser communicates with webapp2, which redirects the browser to sts.contoso.com (the ADFS). sts.contoso.com from externally, points to WAP. WAP terminates the request, proxies the request to ADFS and requests a token. The token is then given to the browser/user, who then returns to webapp2.

    in your Q2, the flow is user@browser -> WAP -> ADFS, where WAP terminates the communication/traffic and requests the token in the name of the user from ADFS.

    Thanks,Florian


    The views and opinions expressed in my postings do NOT necessarily correlate with the ones of my friends, family or my employer. Let's give the thread opener a chance to mark an answer themselves.

    • Marked as answer by Fisher W Tuesday, December 5, 2017 1:09 AM
    Monday, December 4, 2017 7:43 PM
  • Thanks, Florian.

    So it means in the "web proxy" function part of WAP, if using ADFS preauthentication, the "ADFS proxy part" also contributes to the flow. ( I would like to identify the "web proxy" function and "ADFS proxy" as different functional parts in WAP.)

    Tuesday, December 5, 2017 1:17 AM