Multiple and wildcard replyURLs for Relying Parties using WS-Fed

[joelhaslerfhnw]

Multiple and wildcard replyURLs for Relying Parties using WS-Fed

We currently use ADFS 3.0 as a «protocol Gateway» to authenticate SharePoint 2013 against our SAML2-based Identity Provider (Shibboleth). We have some problems with this constellation, because ADFS does not have a user store implemented and therefore each authentication request will pass the whole chain (SharePoint  ADFS  Shibboleth and backwards). For that reason we are investigating if we can replace the ADFS Server with a solution based on IdentityServer3 with the WS-Federation plugin together with Kentor Authentication Services (https://github.com/KentorIT/authservices). The first steps with Identity Server in our POC environment are very motivating Most of the stuff works very well but two issues are still to be addressed:

1. We use SharePoint Add-Ins. The way Add-Ins in SharePoint are implemented is that each app will get a unique random GUID URL based on the following schema: https://apps-GUID.myappdomain.com. (ex. https://apps-bd5b8584-fd5f-49fd-96b2-64b60927924c.myappdomain.com). In ADFS 3.0 it is possible to register a wildcard endpoint for the Add-In Domain like https://*.myappdomain.com.

2. On the other side SharePoint as the Relying Party needs to be configured that the WReply Parameter will be sent, so that the Identity Server knows, where the request need to be redirected. It is possible to register each app URL individually as its own relying Party, but our aim is that each power user can add Add-Ins by himself and then this is no longer working. This lead us to the second point. We need to have one Replying Party with multiple Endpoints (ReplyUrls) registered in Identity Server. This is needed so that the SharePoint Add-Ins are working and also because everything is covered in one realm it helps us for the token lifetime if we switch between the different URLs (applications).

Thank you very much for your help in advance.

Cheers, Joël

[scottbrady91]

Identity Server will only send tokens to reply urls it is aware of before the request is made, for security reasons (it minimizes the attack surface). If this url is compromised in some way, an attacker could start stealing tokens and therefore gain unauthorized access your resources. Wildcard urls are too easily manipulated and this is how some big players have been compromised in the past.

Regarding multiple Reply Urls per Relying Party (like in the core project for OIDC), I don't see why not. Unless this is prohibited by the WS-Fed specification in some way... It'd need to be a PR either way.

[joelhaslerfhnw]

Thank you very much for your feedback. So it means that the IdentityServer support multiple ReplyUrls in theory? Because in the current implementation we saw that the model class RelyingParty does only save one ReplyUrl. Does it mean we need to extend this class?
In the WS-Fed specification the wreply parameter is an optional parameter and is the URL to which responses are directed.

Thanks

[scottbrady91]

In theory it is possible to have multiple ReplyUrls, however this requires changes to both the RelyingParty model and SignInValidator (I think). Either way, the change to RelyingParty model is a breaking change.

I could maybe get a PR ready for the v3 release where such breaking changes are acceptable.

[clairernovotny]

This PR has support for multiple reply url's for WsFed:
#60

And it was just merged in.

[clairernovotny]

Looks like you can also plug-in your own reply validator:
https://github.com/IdentityServer/IdentityServer3.WsFederation/blob/dev/source/WsFederationPlugin/Services/DefaultRedirectUriValidator.cs#L52

So you could put in your own wildcard and implement logic to parse that and satisfy the call.

[scottbrady91]

A collection for PostLogoutRedirectUris was added in #60, however the ReplyUrl is still one per Relying Party. Changing this would be a breaking change.

IRedirectUriValidator is also implemented for post logout redirect urls only.

[clairernovotny]

Oh, sorry, missed the part where you needed it to be on the ReplyUrl param

[joelhaslerfhnw]

Hi,
I am quite new in the github community. Sorry for this bad question, but what are the steps if we like to make a breaking change to have one RP with multiple Endpoints?

Thanks

[leastprivilege]

We would need to add the feature and release a new major version. We are not planning to do that soon.