locked
Publishing Internal Application to be Consumed by Existing Relying Trust Party RRS feed

  • Question

  • Forgive me if this is covered elsewhere, I'm still new ADFS and am having a hard time weeding through all of the information that is available. The company has decided that this project is of utmost importance, so I'm hoping you can help clarify the configuration for me:

    ADFS 3.0, with DMZ-based WAP that is not joined to the domain.

    We have created relying trusts for SSO to an external service in the cloud. This service wishes to call back to an application within our data center using a separate AD service account. 

    The "service layer" application in our datacenter is not SAML-based and is not claims aware. The external vendor wishes to authenticate to our AD and gain access to this app via a URL/URI.

    Can I simply create a non-claims-aware relying trust in ADFS (point it to the internal address of the app) and publish it to the WAP? Will this work without joining the WAP to the domain?

    Any insight on this configuration would be very helpful.


    • Edited by Keldivac Tuesday, August 23, 2016 7:32 PM
    Tuesday, August 23, 2016 7:31 PM

All replies

  • I am not sure I understand the scenario.

    You have a webservice online that want to contact an internal URL?

    If so, yes you can publish this with WAP, using pass through. But there will be no authentication. If you want ADFS pre-authentication, then the webservice needs to be able to provide some sort of identity using a supported federation protocol.


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Friday, August 26, 2016 2:14 PM
  • Thanks for the reply Pierre. 

    I think you have the idea. For the sake of example, let's say that it's Salesforce. We have a trust in place to allow SSO for our internal users to Salesforce, but Salesforce needs to come back into our datacenter to leverage a REST API that we have developed for internal systems. Our company wants to publish the API so that Salesforce can authenticate against AD to access it (with an account that we will provision for them). 

    Our WAP is not domain-joined, and the API is not claims aware, so it doesn't seem to me like there is a way to leverage our ADFS farm in this scenario.

    Monday, August 29, 2016 5:16 PM
  • If Salesforce want to request for a token on behalf a user, you can use the WS-Trust ActAs flow. But I have no idea if Saleforce supports that. There might be other flow available with ADFS 2016 since the support for OAuth2 has been extended...


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Monday, August 29, 2016 6:31 PM
  • They would not be looking to do it on behalf of the federated user, rather a new auth request to a trust that we have published (this portion would be done with a service account). 

    The part we're struggling with is how to provide AD authentication for the service account if the WAP is not domain-joined and the app is not claims aware.

    Monday, August 29, 2016 7:20 PM
  • Do they need info about the user? If so, what about giving that info in the original Token?

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Monday, August 29, 2016 7:33 PM
  • If you're not chaining the authentication flow to the federated logon, then there is no relationship between the fed logon and that of your service-to-service communication flow, i.e. they are independent of one another. If you want AD FS to protect the API, then you may do so via an ActAs token as Pierre mentioned, i.e. in this access to the API layer is only possible when a token is presented on behalf of the federated user to the service layer. This requires support for WS-Trust and calls different endpoints on the AD FS server as we move from passive authentication (via the browser) to active (using a service).

    Alternatively, if you domain-join the WAP then you can publish the service as a non-claims aware RP and use KCD for the URL concerned. Any reason why the WAP cannot be domain joined?


    http://blog.auth360.net

    Monday, August 29, 2016 7:38 PM
  • The WAP sits in the DMZ, and for obvious security reasons we do not extend access to AD into that zone. There have been many situations over the years where people have requested this functionality but the security team has always pushed back.

    The vendor is going to use an independent account for all calls to the API, so, to the best of my knowledge there is no relationship between the user federated login to the vendor and the vendor's login to the API. This is purely for the purpose of providing a reverse proxy and authenticating 1 single account many times. I cannot speak to what the vendor's code does, or how it leverages the token... that's for the dev guys. I am just trying to publish a non-claims aware app in a scenario where the WAP cannot do the authentication.


    Tuesday, August 30, 2016 1:05 PM