U-LINC Security Requirements

When implementing any enterprise software, security is usually a significant part of the implementation.  While we attempted to mitigate as many security requirements as possible, security issues continue to be at the top of our support list.

Understanding the pieces that comprise the U-LINC solution will help end users and partners to identify what potential issues may crop up during implementation and use.

There are three key components to U-LINC Foundation:

1. SharePoint Application
2. Web Services
3. SQL Triggers

From a setup perspective, SQL Server needs to be able to access the Web Services.  Web Services needs to be able to access SharePoint.  SharePoint needs to be able to access SQL Server.  Additionally, if you are using an ERP adapter, the adapter needs to be able to access the Web Services.

Workflow initiation scenario:
When data changes in SQL Server, a trigger fires which contacts the web services.  The web services then interact with SharePoint to create an item in a list.  Once the list item is created, a SharePoint List workflow is initiated.

Creation of an integration:
When a user wants to create a new integration, the SharePoint application creates a trigger in SQL and creates a new list to house items created when data in SQL changes.

Adapter workflow visibility:
When a user displays a record in an ERP system using the associated adpater, the adapter gets the workflow state of the current record using the web services.

Seeing now how these systems interact, you can begin to infer the security requirments. 

In order for SQL Server to authenticate to the U-LINC Web Services, the SQL Server process account must be a domain account.  By default, all domain authenticated users can access the U-LINC Web Services.

In order for the U-LINC Web Services to perform its necessary actions, the application pool account associated with the IIS web site hosting the web services must have "Contribute" access to the SharePoint site where the U-LINC SharePoint application is installed.  Additionally, the application pool account should be a SQL sysadmin on the SQL Server instance which hosts the SharePoint content database.

When the SharePoint application creates SQL Server triggers, it can use Windows Authentication or SQL Server Authentication to make the connection.  This is defined within the U-LINC Application Source.

Our standard recommendation is to create a new domain account and grant the following privileges to the account:

1. Domain User
2. "Contribute" access to SharePoint
3. "sysadmin" permissions to SQL (hosting SharePoint content database)

This account would then be used as the SQL Server Process Account for the SQL instances that house the data you want to do workflow "stuff" on.  Also, this account would be the one used when deploying the U-LINC Web Services from the U-LINC Configuration Manager.

This post covers a portion of the overall security implications of U-LINC.  In a later post, I will cover best practice recommendations for securing your lists which contain the data used for workflow activites.

Wow ... this is fun ... more to come ...