search

SharePoint / sp-dev-docs

SharePoint & Viva Connections Developer Documentation
https://docs.microsoft.com/en-us/sharepoint/dev/
Creative Commons Attribution 4.0 International
1.23k stars 992 forks source link

Register SharePoint add-ins with ACS. How long will this stay supported? #9235

Open waaromikniet opened 9 months ago

waaromikniet commented 9 months ago

According to the new note on this page registrering a new ACS account is now being put behind a new security option. We are still using ACS for some remote event receivers we build on SharePoint online. Webhooks don't offer the sync events. Will ACS continue to be a supported way of creating an ad-in or will this be deprecated in the near future?

Site collection admin is not able to register add-in with Azure ACS in AppRegNew.aspx by default unless explicitly allowed by the SharePoint tenant admin. For more information, see [Set-SPOTenant](https://learn.microsoft.com/en-us/powershell/module/sharepoint-online/set-spotenant#-siteownermanagelegacyserviceprincipalenabled).

Document Details

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

ghost commented 9 months ago

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

VesaJuvonen commented 9 months ago

ACS will be indeed deprecated in near future as the Azure AD should be used for the app registrations. Deprecation means that we will openly communicate that we are no longer investing on the ACS and we will provide a reasonable end of life for the ACS, so that there's enough time to transition. What's reasonable? >18 months minimum.

We have been delaying the deprecation announcement now for a while, but it's expected to happen by end of 2023 calendar year.

waaromikniet commented 9 months ago

There are issues when adding RER's to SharePoint online that connect with an Enterprise Application. https://github.com/pnp/powershell/issues/3169 Ading them requires a user account or an App created via AppRegNew. Thats why we still use ACS. Does this mean RER will be unsupported to? Webhooks can do some but no sync events

waaromikniet commented 9 months ago

@VesaJuvonen, do you have any feedback about remote event receivers support for SharePoint online? Will this also be deprecated? If so we need to rethink our migration strategy.

waaromikniet commented 8 months ago

Does someone else, beside @VesaJuvonen have any idea if remote event receivers will continue to work in the future? I can't find any guidance on this. I my discussion on SharePoint stack exchange (https://sharepoint.stackexchange.com/questions/309639/what-is-the-future-for-remote-event-receivers-for-sharepoint-online/) I learned that when using Webhooks or Power Automate remote event receivers registrations are used to connect to the SharePoint list. So is this tech still being supported or should I step away from the remote event receivers?

imorrish commented 7 months ago

MC693865 · Provider Hosted Apps Retirement Will impact al the RER that were registered using the app... Since the release of SharePoint Add-Ins in 2013, Microsoft has evolved SharePoint extensibility using SharePoint Framework (SPFx) enabling you to write applications that can be used in Microsoft SharePoint, Viva Connections and Microsoft Teams. With our continued investment in SharePoint Framework, Microsoft is retiring SharePoint Add-Ins.

Key Points:

Major: Retirement Timeline: Starting July 1st, 2024, SharePoint Add-Ins cannot be installed from the public marketplace, also referred to as store by existing tenants. Installation from a private tenant catalog stays possible. Starting November 1st, 2024, new tenants will not be able use SharePoint Add-Ins, regardless of their origin (public marketplace, private tenant catalog). Starting April 2nd, 2026, Microsoft will remove the ability use SharePoint Add-Ins for existing tenants. There will not be an option to extend SharePoint Add-Ins beyond April 2nd 2026. Action: Review and assess impact

How this will affect your organization

If your organization still uses SharePoint Add-Ins, they will no longer function after April 2nd, 2026. We recommend customers to port their customizations to SharePoint Framework (SPFx) and ask their solution vendors for updated solutions.

chrisflem commented 7 months ago

@imorrish Your reply, while useful, does not answer the question. Has there still not been a concrete announcement regarding RER ?

waaromikniet commented 7 months ago

I am able to create a RER that uses an Azure App Registration and authenticates using a certificate. This works without ACS. I only want to know if adding RER and event firing for remote event receivers will stay in place

chrisflem commented 7 months ago

This will work in a user context. When you add the event receiver to eg. a list using access tokens from an Azure app it will not fire, until you've added the app to SharePoint using /appinv.aspx. This is because the event receiver needs to be run in the context of an ACS user(as far as I understand). See here for more info: https://github.com/pnp/powershell/issues/464 (Adding the RER as a user is also problematic because if the user is disabled they will stop working, and only that user is able to edit/remove the RER)

RER is also connected to ACS in that if you register it as an app using AppRegNew, then upon triggering it will pass you a Context token that you can consume in ACS to generate an on behalf of token(delegated), for the user that effected the change.

Looking at the migration guide (https://learn.microsoft.com/en-us/sharepoint/dev/sp-add-ins-modernize/sp-add-in-modernize) for the ACS retirement post there is also a point about RER to webhooks.

Based upon this i believe that RERs are getting removed, but looking for a definitive answer. I'll register a support ticked with MS and keep you informed

rmillener commented 6 months ago

Take it we out of luck if we need synchronous event handling beyond April 2026? this is widely used and webhooks are not an alternative.

waaromikniet commented 6 months ago

This will work in a user context. When you add the event receiver to eg. a list using access tokens from an Azure app it will not fire, until you've added the app to SharePoint using /appinv.aspx. This is because the event receiver needs to be run in the context of an ACS user(as far as I understand). See here for more info: pnp/powershell#464 (Adding the RER as a user is also problematic because if the user is disabled they will stop working, and only that user is able to edit/remove the RER)

RER is also connected to ACS in that if you register it as an app using AppRegNew, then upon triggering it will pass you a Context token that you can consume in ACS to generate an on behalf of token(delegated), for the user that effected the change.

Looking at the migration guide (https://learn.microsoft.com/en-us/sharepoint/dev/sp-add-ins-modernize/sp-add-in-modernize) for the ACS retirement post there is also a point about RER to webhooks.

Based upon this i believe that RERs are getting removed, but looking for a definitive answer. I'll register a support ticked with MS and keep you informed

I have tested on my tenant and what I see is that using an Azure AD app with sites.Selected permissions enables us to create a RER which fires without ACS.

We took these steps:

  1. Create an Azure AD app with sites.selected permissions on SharePoint api
  2. Create a certificate and add to the app
  3. Add fullcontrol permissions for the app with Grant-PnPAzureADAppSitePermission on my site collection
  4. Log in with PnP.PowerShell using Connect-PnpOnline [tenant.sharepoint.com] -ClientId [clientid] -CertificatePath c:\temp\certs\test.pfx -CertificatePassword $password -Tenant '[mytenant].onmicrosoft.com'
  5. Add a RER to my list using Add-PnPEventReceiver
  6. Host the RER locally using devtunnel or Ngrok

We see the RER firing after this. I can manipulate the item, execute other logic and return a SPRemoteEventResult

The only thing I am worried about is a error message in the request headers:

"The app i:0i.t|ms.sp.ext|[clientid]@[TenantID] does not have an endpoint or its endpoint is not valid"

It seems to me this is not running in a user context. So will this work? Is this supported and will this stay working?

chrisflem commented 6 months ago

@waaromikniet I've also noticed this. I believe the New-MgSitePermission/Grant-PnPAzureADAppSitePermission creates an ACS user for your SharePoint app.

The error message in the header is because this is not an ACS app registered through /_layouts/15/appregnew.aspx. In There you can setup AppDomain, and if you add an event receiver in the context of this app, where the url to the RER matches the Appdomain, you will get a Token you can use to work on behalf you the triggering user(bit unstable, not always working)

I don't know if it will work after ACS retirement, but I have a hunch that this will probably stop working.

I'm still in the process of getting an answer from Microsoft support, so far every support ticket I've registered has been answered with I need to register a new ticket in another place. Hopefully I can an answer soon

chrisflem commented 6 months ago

@waaromikniet I've heard back from Microsoft Support. RER events are getting retired. See response below:

Hello xxxx,

Hope you are doing well.

Thank you for your response. we have checked on the backend and found the below details for reference. you can refer the below details. I hope this will help you regarding your query.

Yes, remote event receivers are expected to be retired in April 2026 alongside the deprecation of Azure Access Control Service (ACS). As remote event receivers rely on ACS for authentication, they will no longer function once ACS is turned off. Here's what you need to know:

Timeline: • November 27, 2023: SharePoint Add-in model is retired. This means no new investments will be made in the model, but existing add-ins will continue to be supported. • April 2026: Azure ACS is retired, leading to the retirement of remote event receivers. Impact: • Apps relying on remote event receivers will no longer receive notifications about events in SharePoint. • Synchronous events, which allow apps to block or cancel SharePoint actions, will no longer be possible. Alternatives: • Microsoft Graph Change Notifications: These notifications provide a modern alternative to remote event receivers. They offer asynchronous notifications and support for various SharePoint entities. • SharePoint Online Webhooks: These webhooks are another alternative to remote event receivers. They offer a REST-based approach for subscribing to SharePoint events and receiving notifications. Recommendations: • Migrate existing remote event receivers to Microsoft Graph Change Notifications or SharePoint Online Webhooks as soon as possible. • Plan your migration carefully to minimize disruptions. • Consider using the SharePoint Framework for new development instead of the retired Add-in model. Here are some resources to help you with the migration: • Transform SharePoint Add-in model Remote Event Receivers to SharePoint Online Webhooks: https://learn.microsoft.com/en-us/sharepoint/dev/apis/webhooks/get-started-webhooks • SharePoint REST API for Webhooks: https://learn.microsoft.com/en-us/kaizala/connectors/webhooks • Microsoft Graph Change Notifications: https://learn.microsoft.com/en-us/graph/api/resources/webhooks?view=graph-rest-1.0

waaromikniet commented 6 months ago

@waaromikniet I've heard back from Microsoft Support. RER events are getting retired. See response below:

Hello xxxx,

Hope you are doing well.

Thank you for your response. we have checked on the backend and found the below details for reference. you can refer the below details. I hope this will help you regarding your query.

Yes, remote event receivers are expected to be retired in April 2026 alongside the deprecation of Azure Access Control Service (ACS). As remote event receivers rely on ACS for authentication, they will no longer function once ACS is turned off. Here's what you need to know:

Timeline: • November 27, 2023: SharePoint Add-in model is retired. This means no new investments will be made in the model, but existing add-ins will continue to be supported. • April 2026: Azure ACS is retired, leading to the retirement of remote event receivers. Impact: • Apps relying on remote event receivers will no longer receive notifications about events in SharePoint. • Synchronous events, which allow apps to block or cancel SharePoint actions, will no longer be possible. Alternatives: • Microsoft Graph Change Notifications: These notifications provide a modern alternative to remote event receivers. They offer asynchronous notifications and support for various SharePoint entities. • SharePoint Online Webhooks: These webhooks are another alternative to remote event receivers. They offer a REST-based approach for subscribing to SharePoint events and receiving notifications. Recommendations: • Migrate existing remote event receivers to Microsoft Graph Change Notifications or SharePoint Online Webhooks as soon as possible. • Plan your migration carefully to minimize disruptions. • Consider using the SharePoint Framework for new development instead of the retired Add-in model. Here are some resources to help you with the migration: • Transform SharePoint Add-in model Remote Event Receivers to SharePoint Online Webhooks: https://learn.microsoft.com/en-us/sharepoint/dev/apis/webhooks/get-started-webhooks • SharePoint REST API for Webhooks: https://learn.microsoft.com/en-us/kaizala/connectors/webhooks • Microsoft Graph Change Notifications: https://learn.microsoft.com/en-us/graph/api/resources/webhooks?view=graph-rest-1.0

@chrisflem Thanks for the update.

It was my understanding that webhooks and also Power Automate Flows are built on the same remote events that are also used for remote event receivers, See my SharePoint Stack Exchange question about this: https://sharepoint.stackexchange.com/questions/309639/what-is-the-future-for-remote-event-receivers-for-sharepoint-online I was hoping that the events would still fire after ACS retirement.

I also am fallowing the discussion on a post created by @jansenbe https://techcommunity.microsoft.com/t5/microsoft-sharepoint-blog/sharepoint-add-in-retirement-in-microsoft-365/bc-p/4008028#M6814

As you can read there many SharePoint developers would like an alternative for RER and especially sync RER's.

aminezemzemi commented 4 months ago

Hi everybody, Thank you for your explanation. I want to know the context of your call to RER when using Azure App having App permissions ? When user makes an update for a listItem, it fires the event which has application permissions. In this case, what will se in Auhtor/Editor field ? When user has less permissions than App, which permission will be applied ? Can we use Azure App with delegated permissions ?

chrisflem commented 4 months ago

The context depends upon how the code that listens to the RER performs the auth. If using ACS, and an app then the rer will contain a context token, else it will not.

If you have context token, then you can in the listener code use the same app id, and a secret plus the context token to work on behalf of the triggering user, with the same permissions as the user. In the modified field it will read "Modified by {AppName} on behalf of {Triggering user}" (or something close to this)

If you do not have/use the token you can authenticate using either ACS or Azure AD clientId + secret/certificate(client credentials flow). Here you will have the permissions specified by the app. In the modified field it will read changed by sharepoint app.

You can not use Azure Ad app reg with delegated permissions, this is only supported by ACS(You only get the context token needed for delegated access when using an ACS app to register the RER)

aminezemzemi commented 4 months ago

Thank you Chris for you reponse. In my case, I'm not using ACS, only Azure App with certificate. How can I verify the identity of user calling my api ? If he is the good user making the update of item ?

chrisflem commented 4 months ago

You cannot directly verify the user, since you're not getting the ContextToken. What you can do is check who modified he item in SharePoint, to get who triggered the call. If it's more general authentication, you can add a query parameter to the RER url, and verify it. ex Rer-urlHere?ApiKey=key, and verify that the key is trusted(This will work because a regular user cannot read RER data on lists etc)