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.


Get All Workflow Names Including Content Type Reference In SharePoint

Started using this handy method at the advice of a co-worker:


         public static List<string> GetWorkflowNames(SPList list)
            List<string> workflowNames = new List<string>();
            if (list != null)
                foreach (SPWorkflowAssociation workflowAssociation in list.WorkflowAssociations.Cast<SPWorkflowAssociation>().Where(workflowAssociation => !workflowNames.Contains(workflowAssociation.Name)))
                foreach (SPWorkflowAssociation workflowAssociation in
                    from SPContentType type in list.ContentTypes
                    from SPWorkflowAssociation workflowAssociation in type.WorkflowAssociations
                    where !workflowNames.Contains(workflowAssociation.Name)
                    select workflowAssociation)
            return workflowNames;



Strategize SAML Token Based Authentication In SharePoint 2013

The token authentication architecture in SharePoint 2013 is in place for implementing a SAML token based providers with these components:

  1. SharePoint Security Token Service This service creates the SAML tokens for the farm to use. The service is created and started on all the servers within that server farm. This service is used for inter-farm communication because such communication always uses claims based authentication. This service is also used to authenticate with methods for implementing web application that use claims based authentication. This includes Windows, forms based, and SAML token based authentication.
  2. Token Signing Certificate (Import Trust Certificate) This certificate allows you export from an IP-STS and then to copy to a sever in the farm. It can also be added to the Trusted Root Authority list of that farm. This certificate can be used to create an SP Trusted Identity Token Issuer only once. Before you can create another, you have to delete the existing one. Before you can delete it, you have to remove it from all the web applications that use it.
  3. Identity Claim This is the claim from a SAML token and it is the unique identifier for a user. The owner of the IP-STS is the only one that knows the value in the token that will be unique for each of the users. The identity claim is created the same as a regular mapping process for all of the desired claims. The claim that will be the identity is declared at the time that the SP Trusted Identity Token Issuer is created.
  4. Other Claims This type of claim consists of additional claims that stem from an SAML ticket which describes the user. This can include user roles, groups, or other types of claims including age. All of the mapping for these claims are created as objects. They are replicated across the servers in a SharePoint 2013 farm.
  5. Realm The SharePoint claims architecture is the URI or URL associated with a SharePoint web application. It is configured to use an SAML token based provider in order to successfully represent the realm. When the SAML based authentication provider for the farm is created, you have to specify the realms that you want the IP-STS to recognize. You have to do this one at a time. The first realm will be determined when you create the SP Trusted Identity Token Issuer. It is acceptable to add more realms once you create it. Realms will be specified by using syntax. Once you have added the realm to the SP Trusted Identity Token Issuer, you have to create a RP-STS with the realm identifier for the IP-STS sever. This is a process that requires specification of the URL for the web application.
  6. SP Trusted Identity Token Issuer This is an object created on the SharePoint farm. It includes the values required to communicate with and to receive tokens from the IP-STS. When you create it, you have to specify which token signing certificate to use. You can only associate a token signing certificate from an STS with 1 SP Trusted Token Issuer. You can add more realms for additional web application. Once you add a realm, you also have to add it to the IP-STS as it is a relying party. The SP Trusted Identity Token Issuer is duplicated across the servers in the SharePoint 2013 farm.
  7. Relying Party Security Token Service (RP-STS) Each web application that is configured to use an SAML provider in SharePoint 2013 has to be added to the IP-STS server. It needs to be added as an RP-STS entry. There can be many RP-STS entries for a given SharePoint 2013 farm.
  8. Identity Provider Security Token Service (IP-STS) The secure token service in the claims environment. It is responsible for issuing SAML tokens for the users who are included in the associated user directory.

Below is the SharePoint 2013 SAML token claims configuration process:

  1. Export the token signing certificate from the IP-STS. Copy that certificate to a server in the SharePoint 2013 farm.
  2. Define the claim that is to be considered the unique identifier of the user. This is the identity claim. The User Principal Name (UPN) or the email name is often used as the user identifier. By coordinating with the administrator of the IP-STS, you can determine the correct identifier. Only the owner of the IP-STS knows the value in the token that will be unique for each user. Identifying that using identifier is an important part of the claims mapping process. This is done in Windows PowerShell.
  3. Define additional claims mappings from the incoming token that the SharePoint 2013 farm is going to use. The roles of users are an example of a claim that can be used for assigning permissions to resources in the SharePoint 2013 farm. All of the claims from an incoming token that don’t have mapping will be disposed of.
  4. To create a new authentication provider for importing the token signing certificate, use Windows PowerShell. This is the process that creates the SP Trusted Identity Token Issuer. This process allows you to specify the identity claim and additional claims that you have mapped. It is also necessary to create and specify a realm to be associated with the first SharePoint web application. They have already been configured for SAML token based authentication at this point.
  5. Each realm that you add to the SP Trust Identity Token Issuer has to be created with an RP-STS entry on the IP-STS. This can be done before you implement the SharePoint web application. It is important to plan the URL before you create any of the web applications.
  6. With a new or existing SharePoint web application, you can configure it to use the newly created authentication provider. This is displayed as a trusted identity provider in Central Administration. You will see it when you create a new web application.

It is possible to configure many SAML token based authentication providers. Keep in mind that you can only use a token signing certification once per farm though. All of the configured providers will be displayed as options in the Central Administration. The claims from different trusted STS environments won’t conflict with each other.

When you implement SAML token based authentication with a partner company and your own environment with IP-STS, it is a good idea to work with the administrator of your internal claims environment. Establish a one way trust relationship that will be in place for your internal IP-STS and the partner STS. You won’t have to add an authentication provider to your SharePoint 2013 farm to do so. Your claims administrators will be able to manage all of your claims environment. It is very important to understand you won’t have to set network load balancing for a single affinity when you use claims based authentication in SharePoint 2013 Preview.  Any time a web application is configured for use with SAML token based authentication, the SP Trusted Claim Provider class won’t provide search functions for the People Picker Control. Therefore, text that is entered in the People Picker Control will be automatically displayed.