I am setting up a Web Application Proxy as a reverse proxy to publish some of our internal websites to the internet. I am going to publish https://portal.workplace.example as the "hub" site which will link off to various other websites hosted internally. These sites are hosted on various different servers so I want to use the WAP to take advantage of the SSO facility. This works nicely.
One of the links will be to Office 365. We are using IAMCloud's Federate 365 service (which is essentially a hosted ADFS service) to authenticate our user. Using this means that external users are not dependant on our internet connection being active to access O365 and that they will still be able to authenticate should our connection die. However, it also means that when the user clicks on the link to Office 365 they are forced to re-authenticate. What I'd like to is to pass on the credentials that the Web Application Proxy collects onto the external federation service automatically. I just can't see how you'd do it.
I have added the external ADFS farm as a relying party trust but I have no idea what I need to use as a claim rule so I've used a passthrough rule with the UPN as the claim being passed. I've also set up a publishing rule with the WAP with the external federation's URL and changed the hosts file on a test computer to make the external federation's address resolve to the WAP's IP address but this just results in a blank page. I fully accept that I'm not doing this right but I'm unsure of where to go from here. Can anyone give me some advice?
Many thanks,
Ian
Web Application Proxy does not collect external user credentials - user authentication is solely done by ADFS, which is the only authentication provider for WAP. And as @MichelZ noted, you are inserting here a dependency to your on-prem directory :-).
I think the only way to have SSO anytime independently of your interned connection being active is changing all of your on-prem applications to trust the cloud as the identity provider. Otherwise you still have more than one identity provider, which basically removes the possiblity of SSO.