NextLabs SharePoint policy automation architecture design

SharePoint is a widely adopted platform for internal and external collaboration. After SharePoint 2013 introduced social feature, cloud integration, and easy sharing capability, enterprises using SharePoint find that SharePoint sites have a tendency to grow at an uncontrolled pace, in part due to the ad-hoc collaboration and discretionary access control model native to SharePoint. This can catch data owners off-guard, especially when it comes to ensuring that sensitive information is protected. In our case, we company has major acquisitions and spin offs. As a result IT security team requested to block certain users to access some identified confidential SharePoint site collections regardless of the SharePoint native access control. In other words, we would need to block the certain users to access those identified SharePoint site collections even they have been granted the access.

NextLabs’ Entitlement Manager for SharePoint is a content aware Entitlement Management solution that provides the capability to authorize, classify, enforce and audit enterprise resources across Microsoft SharePoint. NextLabs Entitlement Manager for SharePoint is designed to enforce policies that control whether and how users can access, download, and use the data stored on a SharePoint server. Compliant Enterprise policy is composed of policy components like site URLs. Policy components are logical constructs that are created in the Policy Author and reused across policies. SharePoint policy can be defined with User (like block User Group), Action (like deny), and Portal components (like list of site URLs), along with conditions as illustrated in the following example for our company, highlighted respectively: 

Only block users that is in AD Group1 to Access highly restrictive list of site collections that any owner in certain departments during any hour.

Since site collection could be provisioning anytime and users could be transferred from one depart to a different one. It would be impossible to manually update the site collection list as policy components. The challenge is how can we automatically build the policy components to accomplish this “dynamic” policy? Let us review the NextLabs’ Entitlement Manager first to design the automation architect.

The Entitlement Manager for SharePoint has the following components.

• Policy Author (Java application): Defines, manages and deploys SharePoint policy.
• Control Center (J2EE server): Stores policy in a central repository and deploys policy sets to distributed Entitlement Managers for SharePoint across the enterprise.
• Administrator (Web application): Monitors system health and checks that policies are up-to-date for each Entitlement Manager.
• Entitlement Manager for SharePoint (Windows service): Detects user actions and enforces policy.
• Reporter (Web application) – Monitors real-time activities and queries the Entitlement Manager for SharePoint logs to analyze and audit trends and patterns.

The two primary components are the Adapter and the Policy Controller. The Adapter runs inside IIS and the Policy Controller as a Windows Service as indicated in the below graph.

   

Adapter

The Adapter functions as the Policy Enforcement Point (PEP) by detecting user actions on SharePoint, obtaining a policy decision from the Policy Controller, and enforcing policy. It is tightly integrated with ASP.NET and SharePoint with the following event monitoring and blocking interfaces:

• Event Receiver – SharePoint provides synchronized event receivers that expose a limited number of events that can be controlled through this high level interface.

• HTTP Module – ASP.NET provides a low level interface to pre-process HTTP requests. This interface provides added event controls that are not supported by the Event Receiver.

When a monitored event occurs, the Adapter sends a policy evaluation request to the Policy Controller through the .NET Adapter SDK. The Adapter uses the same public interfaces in the SDK that can be used to extend the Compliant Enterprise policy enforcement platform to any .NET application.

The Entitlement Manager for SharePoint not only enforces policies but also notifies end-users with customizable notifications to alert and educate users. The notification message can be customized for each policy using the Policy Author.

When the Policy Controller returns a denial decision, it includes a notification obligation for that policy. The Adapter blocks the action and triggers a SharePoint error to display the customized message.

Policy Controller

The Policy Controller is an independent run time that provides the following policy management and evaluation services:

• Police Engine – functions as the Policy Decision Point (PDP) for fast policy evaluation across multiple dimensions.

• IceNet Client – communicates with the Control Center to download policies, upload activity logs, and provide the Adapter health status.

• Obligation Manager – dispatches notification obligations to the Adapter, executes email notification and logging obligations internally, and launches any executable to perform custom obligations.

Now the key part for the automation is how we could automate to push the policy to Policy Controller. We would need to look at the policy components. SharePoint policy can be defined with the following three major components.

• User - AD group with specific attributes
• Action - deny, allow, or report
• Portal components - list of the site collection URLs as example

These three components is indicated in the following Policy Stdio. The three components are highlighted.

Since the user for the specific groups can be identified dynamically from claims SID, it will not require any change. The only  change required is the site collection list for the portal components as in the below screenshot.

At this point, it is cleat the the automation goal should update the policy site collection URLs automatically. Here is the architect design for the automation.

We have two scheduled jobs. 

One schedule job is on SharePoint server to run query against SharePoint using SharePoint server API and generate the site collection list. The site collection list will be written as portal component xml format on NextLabs Control Center (CC) server. 

The second schedule job is on NextLabs Control Center (CC) server. This job will pick up the portal component xml, import, submit, and deploy the policy. Then the deployed policy will be pushed to Policy Control on SharePoint side. As a result, the policy will be applied to SharePoint. The automation architect is described as the following picture.

Here is the detailed design for the automation process. We create the policy through Policy Studio and configure the following automation to update the site URLs in portal component.

1. SharePoint scheduled job - window console app to read SharePoint configuration as query criteria and policy template for xml format. 
2. SharePoint scheduled job - window console app to query SharePoint through server API and generate SharePoint site collection list as NextLabs portal component xml input file.
3. Import tool to read portal component xml and submit to Control Center.
4. Import tool to send portal component Control Center to approve.
5. Entity Deploy tool to deploy the portal component.
6. Control Center ICENET server to ready administration configuration like push setting.
7. Control Center ICENET server push policy to Policy Controller server on SharePoint server

At this point, SharePoint will have the updated new policy and the policy will be enforced. We will publish the detailed automation scripts in different blog.