SharePoint Online har en lättanvänd behörighetsstyrning där en administratör tilldelar användare olika rättigheter till resurser såsom SharePoint-listor, direkt i webbläsaren, utan någon kod eller avancerad logik. Behörigheter sätts för enskilda användare, grupper och även för externa användare.
För enklare applikationer brukar möjligheterna som erbjuds out-of-the-box i SharePoint Online vara mer än tillräckliga. Däremot börjar de inbyggda begränsningarna märkas när man ska skapa avancerade lösningar.
Utmaningar
När vi bygger skräddarsydda applikationer i SharePoint Online, oavsett om det är en Web Part eller SharePoint Extension, används listor flitigt som datakälla. Det finns flera fördelar med detta: det går enkelt att koppla Flow eller LogicApps till listor i SharePoint Online, vi kan utnyttja det moderna gränssnittet för att redigera innehåll och skapa listvyer, samt använda oss av den inbyggda behörighetsstyrningen som finns i SharePoint Online.
Detta standardupplägg passar dock inte för alla typer av applikationer. Många av de lösningar som har sitt ursprung i andra plattformar såsom IBM Notes eller SharePoint On-premise, förlitar sig på olika former av mer ”finmaskig” behörighetsstyrning som inte stödjs som standard i SharePoint Online. Vi tänker här på behörigheter för enskilda fält eller läs- och skrivbehörighet som baseras på ett visst värde i ett fält.
En möjlig lösning
När man arbetar med Web Parts är ett alternativ att dölja de bakomliggande listorna som används och deras formulär. Detta görs genom att lägga till filtrerade vyer för listorna, samt att byta ut standardformuläret mot en tom PowerApp. Vi ser till att vyerna verkligen är tomma genom att filtrera på ett värde som garanterat inte kommer att förekomma, till exempel alla dokument med -1 som Id. Administratörer ser fortfarande alla listor och deras formulär genom att lägga till personliga vyer som bara de kommer åt.
Eftersom vi har dolt formulär och vyer för användarna kan de bara använda gränssnittet i Web Parten för att läsa och skriva data till listorna, men inte komma åt själva listan direkt. I Webparten implementerar vi också egen logik för att kontrollera användarens behörigheter och döljer knappar eller information i gränssnittet som slutanvändarna inte ska kunna se.
För vissa mindre känsliga applikationer kan det vara en acceptabel lösning, men det innebär ingen ’riktig’ säkerhet. En användare som har kunskap antingen om JavaScript eller om hur SharePoint Online bygger upp sina URL:er kan komma åt innehållet i de bakomliggande listorna ändå.
En bättre lösning
För att vara helt säker på att behörigheterna blir rätt är det bästa sättet att se till så att användarna inte har någon åtkomst alls till de listor som ska skyddas. Detta kan låta lite drastiskt och kanske oanvändbart, men det är inte den kompletta lösningen. Istället för att applikationen kommunicerar direkt med listan i SharePoint Online så jobbar den mot en Azure Web App. Web Apps är en lösning som erbjuds i Microsoft Azure där det snabbt och enkelt går att sätta upp en exekveringsmiljö för olika plattformar så som Node.js, Java, PHP, .NET med fler. Istället för att hantera en virtuell maskin så behöver vi bara driftsätta koden. Azure tar sedan hand om exekvering och skalning.
Azure Web Appen integreras mot SharePoint Online och kör med fulla behörigheter till listan vi vill begränsa åtkomst till. När en användare anropar appen för ett t.ex. redigera ett dokument kan denna avgöra om användaren har rätt till att utföra operationen i fråga: detta baseras på vem användaren är, vilka värden som finns i dokumentet eller grupptillhörighet. Om Azure Web Appen avgör att användaren har behörighet kan den utföra operationen med högre behörighet än vad användaren själv har i SharePoint Online.
Den bästa lösningen
En ännu bättre lösning än att använda en Azure Web App är att använda Azure Functions. Det är en tjänst som erbjuds i Azure där kod körs med automatisk skalning, resurstilldelning och exekveringsmiljö. Till skillnad från en Azure Web App så går en Azure Function i vila när den inte körs och exekveringsmiljön stängs ner, d.v.s. en ’serverless’-applikation (eller Function-as-a-Service). Konceptuellt fungerar lösningen med Azure Functions väldigt likt den med Azure Web Apps: användaren har ingen behörighet att jobba direkt mot listan i SharePoint, men kommer åt den genom att gå via Azure Functions.
En fördel med Azure Functions jämfört med Azure Web Apps är prismodellen. Med Azure Functions betalar du enbart för den tid du faktiskt kör, medan du för Azure Web Apps betalar en avgift så länge din server är uppe. En nackdel med Azure Functions är att det tar lite tid för funktionen att starta efter att den har gått i vila, en så kallad ’cold start’. Med regelbunden trafik är detta inget stort problem och vägs oftast upp av prisskillnaden.
Både Azure Functions och Azure Web Apps har en inbyggd integration mot Azure AD, vilket innebär att det går att se till så att enbart användare inom organisationen kan anropa tjänsterna i fråga. Detta ger en yttre försvarslinje för att se till att information inte kan spridas utanför organisationen vid eventuella buggar i implementationen.
Innan man blandar in Azure Functions, Azure Web Apps eller någon annan lösning för granulära behörigheter bör man fundera på om det verkligen är nödvändigt. I vissa fall kan behörighetsmodellen som erbjuds i SharePoint Online vara tillräcklig, speciellt om man tänker till och strukturerar data i olika listor med skilda behörigheter. Det är även bra att tänka på vem man faktiskt försöker skydda sig emot, samt konsekvenserna av eventuellt missbruk. Om implementationen av en säkerhetslösning kostar mer än missbruk av applikationen kanske man är lite fel ute.
