Security In Business Connectivity Services In SharePoint 2013

There are some types of authentication scenarios where the external system isn’t allowed to accept credentials directly from Business Connectivity Services. Yet the external system is able to accept them from 3rd parties and an authentication service that it is able to trust. That 3rd party is generally going to be a security token provider.

 They will accept a grouping of information called assertions about a user. The entire grouping is called the claim, and it can have plenty of information about the person requesting it. This can extend well beyond the username and password. The claim may contain metadata including the email address of that requestor or a security group that they belong to.

 With 3rd party authentication, the service performed will create a security token from the user. The Business Connectivity Service is then going to present that security token to the external system. It will look to see what the data is that the user is authorized to have access to.

When the external system in use doesn’t support credentials based or claims based authentication, then you have to create a customized solution that will take your own needs into consideration. It will take the credentials that you create with Business Connectivity Services and create a format that the external system is going to accept. This is possible to create for OData that has been secured either with OAuth or a custom ASP.NET HTTP module.

You are going to have to find out what the stakeholders of the business see as the solution as well as how they feel users should interact with it. They may need to interact with the data through Apps for Office, External lists, External web parts, Office 2013 , On premises SharePoint installation, SharePoint Online, and SharePoint Server.

The way in which the users will access the data determines how you will set up the external content type for Business Connectivity Services. This is how the users will be able to access that external data. When Business Connectivity Services offers a solution requiring apps for Office and SharePoint application, the external content type has to be customized to such an application.

If you don’t have to rely on apps for Business Connectivity Services, then the external content type has to be developed for the Business Data Connectivity only. Such external content is stored in the BDC Metadata Store. With on premises SharePoint 2013 installation, the external content type is stored in the BDC Metadata Store. A farm administrator will need to manage the security for them.

It is possible to share those external content types with multiple Business Connectivity Services web application. With SharePoint Online, the external content types have to be stored for you to use them in an all on site collection. The apps for SharePoint and Office scoped external content gets stored as XML file in the app for these applications. They can’t be used by other apps regardless of if they are on premises or SharePoint Online.

The connection setting objects offer the connection information including Names for any certificates required, Service address for the external data, Type of authentication in use, and URL.

With connection settings objects, they are separate from an external content type. The Business Connectivity Services solution has to connect with an external system. It uses the information that you select to define that connection separately from the external content type that was developed. You can only use connection settings objects with OData. Both of the apps are external content types.

The connection settings objects get managed in SharePoint Central Administration. All of the solutions have to be granted permission to use connection settings object. They can be used by multiple Business Connectivity Service solutions.  If the apps for SharePoint and Office are accessed through an OData source, you can create an automated app scoped external content type.

This is completed with the use of Visual Studio 2013. It has tools built into it that allow you to create external content types. Just point the Visual Studio 2013 at the OData service URL. The external content type can be used by an external data list. The app scoped external content type can also be used with a custom code including .NET using CSOM or JavaScript using JS CSOM.

You will have to include in your plan who will have permissions for which objects within that Business Connectivity Services solution. You will be able to grand as well as to restrict access based on the solution that you select. You will need to work with the external system administrator as well as the farm administrators for SharePoint to successfully set this up. The online administrators can configure the permission. There are three roles that must be involved with any Business Connectivity Services solution:

There are many roles that fall into this particular category. They include Managing permissions on the external system, Creating and managing Business Data Connectivity Service application, Importing Business Data Connectivity models, and Managing permissions on the BDC Metadata Store.

The SharePoint farm administrators have to be involved with publishing the application and creating the management connection objectives if the apps for SharePoint are using Business Connectivity Services.

This role involves understanding the various business needs for the solution. The common tasks include Creating external content types, Creating BDC models, and Creating the apps for SharePoint that Business Connectivity Services will use.

These are the users that will manipulate and use the external data from the Business Connectivity Services solution. There can be many user roles for a solution, and the users can have different levels of permission. That level will depend on their role within the organization.

There are four main elements to all Business Connectivity Services solutions that have to have managed permissions:

Each external system needs a method for authentication to take place as well as for authorization. Working with the external system administrator allows for identifying a method to grant access to the solutions users that are parallel to the principle of least privileges. This offers a mapping of groups of users from the Business Connectivity Services to a single account on the external side of things.

It will restrict access until a user has been authenticated and authorized to access data. Mapping between individual accounts and each system is also a possibility to consider. The external system will need to use the Secure Store Service though for authentication unless the credentials are already found within SharePoint.

The central infrastructure of the Business Connectivity Services has to be looked at because it is a shared service application. It has to be configured and managed so that the permissions are accessible through Central Administration. Creating a shared service application requires the rights of a farm administrator.

It is an option to delegate administration to Business Data Connectivity service application after you create it. You can manage the assignment of permissions to BDC Metadata Store too in Central Administration. The permissions assigned allow for management of BDC models, External content types, and External Systems.

It is necessary to assign and execute permissions for an external content type to all users within the Business Connectivity Services solution. The tables below show a detailed mapping of those objections, permissions, and abilities.


Planning Security When Migrating To SharePoint

This is a guest post by Benjamin Niaulin from Sharegate

Planning Security when migrating to SharePoint

Whether you are migrating from a shared drive or from SharePoint there will come a time where you will need to sit down and think about permissions. Many companies have specific requirements when it comes to security and permissions. When migrating to SharePoint, one step that is often looked over too fast or too late is managing permission levels and security groups.

Understanding the SharePoint security basics

One thing we learn quickly in SharePoint is that users will only see what they have access to. This is called Security Trimming. The concept is a welcomed addition to the basic security measures we were used to in file shares. I see the Salary folder but I can’t access it is something that you won’t live anymore thanks to the Security Trimming applied by SharePoint.

But other problems arise in SharePoint when security isn’t planned before migrating content to it. Search is a very powerful tool. Search will bring results from all over the place back to the user searching it. This is great if your content is properly secured. However, in most SharePoint implementations that I have seen there was no strict security governance in place. So it started off well with great intentions, then the Power Users grew in numbers and so did the number of bad security practices. This meant that the Search Results would show documents from some Site Collection the user did not know he had access to and in my cases shouldn’t.

Power Users will need to get comfortable with the basics and the governance in place.

SharePoint Groups
One thing to understand is that the SharePoint groups that are created only exist in the Site Collection where they were created. They cannot be used across Site Collections. On the down side, some Site level administrators may think the groups only exist in their site. That is probably one of the biggest issues I have ran into.

SharePoint Permission Levels

Of course, after understanding groups we need to clarify permission levels. This is the level of rights we give to a SharePoint User or Group. From Full Control to View Only there are a few levels available. The key is to understand them properly. By clicking on a Permission Level in your Site Settings, you will see a detailed list of what this Permission Level actually grants.

A common practice is to create a new Site Owner Permission Level that only grants the owner of the site with what you want them to do. I usually remove the right to create sub-sites, this helps the SharePoint team not only maintain a good control over the architecture but also guide the users accordingly when their requirements change.

Migrating documents from file shares

Now that we’ve covered the basics of SharePoint security, we can talk about migrating documents over. If you are looking into more information on how to decommission file shares, check out this post.

Files and folders on your Shared Drives have been using a permission hierarchy since the dawn of time, well maybe not that long but for a very long time. Migrating all of these to SharePoint could prove to be a very long and painful task. Why? SharePoint doesn’t use the same method of assigning permissions as file shares. In fact, SharePoint stores this information in a database, so the more we Stop Inheritance the more requests are sent to the database and the slower SharePoint gets. Stopping Inheritance means telling SharePoint that you no longer want to use the set of permissions assigned to groups and users from the parent object.

This means that a lot of your architecture will be adapted based on the security requirements of your Files when migrating to SharePoint.

I have rarely done this without the help of SharePoint Migration tools that help map the appropriate permissions when migrating. This makes the job a lot faster and a lot easier.

In short

Remember to plan the SharePoint Groups you will be using as well as Permission Levels. Then, when preparing the actual SharePoint Migration, try to use mapping tools to help you see what permissions will be applied to whom and where. Hope this helps.

 Biography Benjamin Niaulin

Benjamin Niaulin works as a SharePoint Geek at Sharegate, a Montreal-based software development firm specialized in SharePoint migration.

Passionate about SharePoint, Benjamin has been helping people around the globe reaching their goals by simplifying SharePoint solutions. With his Microsoft Certified Trainer certification and over 5 years of Training and Speaking experience, he has acquired the skills needed to help everyone understand and use SharePoint.


User Profile Database Architecture In SharePoint 2013

When creating a User Profile service application, there are three databases offered for storing that information in SharePoint Server:

  1. Profile Database Storing user profile information
  2. Synchronization Database – Storing configuration and staging information for the profile data from external sources including AD DS.
  3. Social Tagging Database Storing social tags & notes created by users. Each of them is associated with a  specific profile ID.

All three of these databases can be accessed by Team Sites, My Sites, and other sites within SharePoint. Access points depend on the User Profile service application so that they can have a personalized experience. 

There are other relating service applications in place that the User Profile service application relies upon. This allows for the full range of social computing features that are offered from SharePoint Sever to be accessible. There are several related service applications offered including:

  1. Manage Metadata Service This allows for managing metadata and share content types to occur. It can be done across web applications and site collections.
  2. Search Service Application This is necessary for the people search to be enabled so that a user can gather more information.
  3. Business Connectivity Services This allows for populating properties of existing user profiles from a business system through profile synchronization.