Sp-dev-docs: RER and Windows Authentication

[ivanbilokon]

What about RER hosting and authentication? I didn't find information here what authentication options should be set up in the service but some articles say that the receiver service can only work with anonymous authentication (e. g. https://sptechjournal.wordpress.com/2015/07/26/sharepoint-2013-hosting-remote-event-receivers-in-iis/)
In my case (SPF 2013) I was able to make receiver working only with anonymous authentication but there are another worries about security because default client context retrieval code inside event receiver does not check who calls the service.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 22e75925-b939-1b47-cca8-5a4aaa452e90
• Version Independent ID: 3d6e85ec-30bc-6c69-7cd3-ca07081ea79b
• Content: Create a remote event receiver in SharePoint Add-ins
• Content Source: docs/sp-add-ins/create-a-remote-event-receiver-in-sharepoint-add-ins.md
• Service: unspecified
• GitHub Login: @spdevdocs
• Microsoft Alias: spdevdocs

[flaviuc]

I can confirm Anonymous is required for RER, this is hard-coded, SP does not send ANY authentication information with RER calls. This is because if the RER needs to callback into SharePoint it can use OAuth. Also the only way to address the "anyone can call the RER" concern is to put the RER behind a network device (firewall, proxy) that can verify the source and filter requests that are not coming from the SP servers. In the end IMHO RERs are only meant as a simple "signaling" system.

[ivanbilokon]

@flaviuc
Create an add-in event receiver in SharePoint Add-ins says that in production environment I have to avoid custom port number (I have no idea why and the document doesn't explain). In this case firewall cannot be used effectively

[flaviuc]

RERs sit in their own folder... https://support.microsoft.com/en-us/help/324066/how-to-restrict-site-access-by-ip-address-or-domain-name something like this should work... IP based restriction in "local" web.config

[ivanbilokon]

@flaviuc
Anyway such a considerations and instructions should be reflected in documentation as well as big red WARNING about security hole in default RER implementation that comes from Visual Studio item template. This is main reason I opened the issue.

[andrewconnell]

The documentation states the requirement that production endpoints for the RER cannot include a port number. Therefore it is documented... not sure what action is requested from this issue...

Can you please clarify?

[IvanBil]

@andrewconnell

@flaviuc
Anyway such a considerations and instructions should be reflected in documentation as well as big red WARNING about security hole in default RER implementation that comes from Visual Studio item template. This is main reason I opened the issue.

[andrewconnell]

That's just a copy of what was posted above... my comment was stating that based on what I have read, I'm not clear what is being requested.

@ivanbilokon said:

"considerations and instructions should be reflected in documentation"

I read the thread as talking about ports. The doc is clear in stating: "The URL of a production receiver cannot specify a particular port. This means that you must use either port 443 for HTTPS, which we recommend, or port 80 for HTTP."

So... it is documented... and therefore I'm not clear what is being requested.

@ivanbilokon said:

big red WARNING about security hole

What security hole? There is no security hole... when a RER fires it submits an HTTP POST to the specified endpoint. The payload includes a token which your service can inspect to ensure it came from SharePoint.

[ivanbilokon]

@andrewconnell sorry for not being clear. I'll try to clarify what I meant.
If I create event receiver via default project template it creates some service with some basic ClientContext retrieval code via TokenHelper class:
using (ClientContext clientContext = TokenHelper.CreateRemoteEventReceiverClientContext(properties))
If I look at the CreateRemoteEventReceiverClientContext implementation I find this:
if (IsHighTrustApp()) { return GetS2SClientContextWithWindowsIdentity(sharepointUrl, null); }
This code ignores any token information that could be passed to the helper from SPRemoteEventProperties. In this case we still have security hole if we leave the default code as is.

I agree that code sample in the article may not have the same issue (actually I don't remember because that was a year ago). But the article does not say that I need to make the service accessible anonymously, how to make that working and what security impact does it have in case of high trust apps.

[andrewconnell]

The ProcessEvent() method passes in an instance of the SPRemoteEventProperties which contains the ContextToken submitted in the request.

In the code in the doc, there's a section with the comment //If there is a valid token, continue. That's exactly what you should to validate the call is coming from SharePoint. SharePoint includes a context token in the HTTP POST when an RER fires that TokenHelper can validate it was signed by SharePoint / Azure AD / ACS (_I forget which one as it's been a long time, but it's irrelevant_).

The sample code in any File > New Project experience in Visual Studio may not be 100% hardened for your liking. The goal of all VS projects is to get to you a working solution OOTB as fast as possible.

To your point:

But the article does not say that I need to make the service accessible anonymously, how to make that working and what security impact does it have in case of high trust apps.

I guess it's not mentioned because it's not required. Your initial post above stated _"What about RER hosting and authentication? I didn't find information here what authentication options should be set up in the service"_ ... the doc doesn't mention it because you don't do that. SharePoint isn't going to authenticate with the remote service... it just simply doesn't work that way.

The service is secured with the context token SharePoint provides. The guidance is for the service to be configured to only work on SSL to sure someone isn't jumping in the middle.

[ivanbilokon]

@andrewconnell Now overall idea is clear. Thanks.

[andrewconnell]

Cool... happy to clear this up!

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues