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.


Strategize App Authentication In SharePoint 2013

App authentication is the validation of an external app for SharePoint’s identity. It also allows for the authorization of both the app and an associated user. For this to occur, the app requests access to a secured SharePoint resource. An external component from SharePoint Store App or an App Catalog App that is located on the intranet or internet attempts to serve content. This allows for a new set of functions to be achieved. It enables the apps to include data that comes from SharePoint resources that can be displayed for users.

In order to provide the requested resources from an app through SharePoint, the server has to run SharePoint 2013. It must be able to perform the following:

  1. Verify the requesting app is trusted
  2. Authenticate the requesting app. The server that runs SharePoint 2013 must be configured to trust the app sending it.
  3. Verify the type of access that the app is requesting has been authorized.

Authorize access of the app set permissions from SharePoint 2013. These permissions are associated with the user who the app is working for. It also relies on the permissions that have been granted to the SP App Principal when the trust was established with the Set-SP App Principal Permission Windows in Powershell cmdlet.

For app authentication to work in SharePoint 2013, it is separated from the user authentication. It isn’t used as a sign in authentication protocol for the SharePoint users. The app authentication will use the Open Authorization (OAuth) 2.0 Protocol. It isn’t added to the set of user authentication or sign on protocols including WS Federation. This is why app authentication and OAuth don’t appear in the list of identity providers.

There are several tasks involved with planning for app authentication including:

  1. Identify the set of trust relationships that have to be configured on a farm that will run SharePoint 2013. They need to correspond to the external apps that will be able to make request for SharePoint resources.
  2. Provide incoming access that will be hosted by the internet from external applications.

All web applications that include app authentication endpoints for the incoming requests by apps for SharePoint 2013 have to be configured to use SSL. This can be configured with OAuth in SharePoint 2013 and that doesn’t require SSL. You will need to plan for app authentication with a SharePoint farm if you are using 1 or more external apps that share their external resources through SharePoint.

It is necessary to configure the SharePoint farm so that it can trust the access tokens for corresponding to the resource requests. They will need to allow the following types of external apps to send:

  1. Autohosted apps that run as web role for Windows Azure and that use the Windows Azure Access Control Service (ACS) in an effort to get the access token.
  2. Autohosted apps will need to be configured so that the SharePoint farm is able to trust the ACS instance of the autohosted app.
  3. With provider hosted apps, they will need to run their own servers on the internet or intranet. They need to be registered with Windows Azure and use ACS in order to obtain the token for access.
  4. Provider hosted apps will need to be configured for the SharePoint farm to trust the ACS instance of the provider hosted app.
  5. High trusted apps will run on stand-alone servers on the intranet. They use a signing certificate to digitally sign the access tokens that the app will generate.
  6. High trust apps will need to be configured so that the SharePoint farm and JavaScript Object Notation (JSON) metadata endpoint for the server is a host for the app. It is also possible to configure the trust manually.

When there is an external autohost or provider host app on the internet, you must configure a reverse web proxy. This will be used to perform the authentication and to request resources from intranet SharePoint farms. The configured reverse web proxy found at the edge of the network needs to allow incoming HTTP over SSL connections from the apps to your SharePoint farms.

You will need to identify the HTTPS based URLS that the external applications are going to access and configure. This allows the reverse proxy to publish those URLS and to provide the right level of security.

With high trust apps, they generate their own access tokens. This includes an assertion of the identity of the user who they are acting on behalf of. The server running SharePoint 2013 also services the incoming resource request. This allows the request for a specific SharePoint user to be resolved. This process is called re-hydrating the identity of the user. This is different from app authentication for auto hosted or provider hosted apps. They will identify the user but not assert them.

When rehydrating the identity of the user, the server runs SharePoint 2013 to take the claims from the incoming access token. Then it will resolve it to a specific SharePoint user. The default for SharePoint 2013 includes the built in user profile service application as the identity resolver.

 There are key attributes for users through the identity re-hydration including:

  1. Windows Security Identifier (SID)
  2. Active Directory Domain Services (AD DS)
  3. User Principal Name (UPN)
  4. Simple Mail Transfer Protocol (SMTP)
  5. Session Initiation Protocol (SIP)

The app must have at least 1 of these user attributes in place. That attribute must be current in user profiles. It is recommended that you periodically sync from identity stores to the user profile service application. SharePoint 2013 expects 1 entry in the user profile service application for a given query. It can be based on these attributes. It can return an error condition if there are multiple user profiles found. That is why it is recommended to delete older user profiles from the user profile service application on a regular basis. If there are user profiles and group memberships not synced, then the user will experience a denial of access when they try to access a given resource. To avoid this, always make sure the memberships are synced with the user profile service application.


App Authentication Overview In SharePoint 2013

Within SharePoint 2013, user authentication is the validation of the user’s identity for a given authentication provider. This is the database or directory that contains the credentials for the users. This is used to verify that the user has submitted the correct information. When user authentication occurs, a user has successfully attempted to access a resource offered by SharePoint.

There are two types of authentications that occur for user authentication within SharePoint 2013 Preview:

  1. Claims based authentication
  2. Windows classic mode authentication

With a claims based authentication, there is a claims based security token in place. This is what is generated by the SharePoint Security Token Service (STS). With a windows classic mode authentication, there is a Windows security token. It is recommended that you rely on claims based authentication for your user authentication.

With SharePoint 2013, there is app authentication which is the validation of a remote SharePoint app identity. The authorization of the app is for an associated user of a secured SharePoint resource. App authentication happens when there is an external component of a SharePoint Store app or an App Catalog app. For example, when the web server located on the intranet or internet attempts to access a SharePoint resource that is secured.

If the SharePoint app doesn’t require a secured resource from SharePoint to make the page available to the user, app authentication won’t be necessary. For example, any SharePoint app that provides a stock quote and gives access to stock information through a server on the internet. It won’t require app authentication, so it can be done with the use of the SharePoint 2013 products.

 There are two processes involved with app authentication:

  1. Authentication Verifying the application has registered correctly with a common trusted identity broker.
  2. Authorization Verifying that the application and the associated user requesting have the appropriate permission to perform such an operation. This includes accessing a folder, a list, or completing a query.

In order for app authorization to be performed successfully, the application needs to obtain an access token. This comes from either the Windows Azure Access Control Service (ACS) or by self-signed tokens that are used through a certificate SharePoint 2013 trusts. The access token allows the request for access to the specific SharePoint resource. This contains data that identifies the app and the associated user rather than validating the credentials of that user. It is important to understand that the access token isn’t the same as a logon token.

It is important to point out that the SharePoint Store app has access to the SharePoint server resources but it doesn’t have to obtain the credentials of the user to do so. The access is authenticated through ACS and that is trusted by the server running SharePoint 2013. Then it is authorized through the set of app and user permissions.