In my prior two posts I demonstrated how WAAD can be configured as IdP. In this post we document this on paper. The configuration is very simple, but so far I could not find it documented anywhere, so here it is for anyone interested.
In first scenario we will configure WAAD as IdP for Azure ACS. Like shown on this diagram:
Image may be NSFW.
Clik here to view.
To configure ACS as relying party in WAAD you need to do the following:
- Add new application in your WAAD tenant
- Name it whatever you like it
- For App URL:, put the following URL https://<your-acs-name>.accesscontrol.windows.net/ , where <your-acs-name> is the name of the ACS you created in your Azure subscription.
- For App ID URI:, put the same URL as in previous step.
- Save configuration.
Of course you’ll need to add WAAD in ACS as IdP as well.
In second scenario we will configure WAAD as IdP for AD FS. Like shown on this diagram:
Image may be NSFW.
Clik here to view.
To configure AD FS as relying party in WAAD you need to do the following:
- Add new application in your WAAD tenant
- Name it whatever you like it
- For App URL:, put the following URL https://<your-sts-dns-name>/adfs/ls/ , where <your-sts-dns-name> is the URL for your AD FS server (for example sts.cloudidentityblog.com)
- For App ID URI:, put the following http://<your-sts-dns-name>/adfs/services/trust, where <your-sts-dns-name> is the URL for your AD FS server (for example sts.cloudidentityblog.com).
- Save configuration.
Of course you’ll need to add WAAD in AD FS as IdP as well.
There is no mechanism to configure WAAD as to what type of claims it will provide to RP. It is hard coded to provide half a dozen claims for the user. If you need to get information about the user that is not passed via claims you’ll have to use Graph API to query WAAD and find that information programmatically (your app will have to do this).
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
