Share via

Plan security for Duet Enterprise

  • Article

 

Applies to: Duet Enterprise for Microsoft SharePoint and SAP

This article discusses how to plan for secure deployment and operations of Duet Enterprise for Microsoft SharePoint and SAP. It presents the Duet Enterprise security architecture, describes security configuration strategies for common Duet Enterprise scenarios, describes how to configure permissions in Duet Enterprise based on SAP roles, describes how to help implement security for various elements of the Duet Enterprise environment, and describes the roles and accounts that you must have to manage Duet Enterprise securely.

Important

This article discusses Duet Enterprise security planning within the context of a Microsoft SharePoint Server server farm. For a related discussion of Duet Enterprise security from inside the SAP environment, see the SAP Duet Enterprise Security Guide on the SAP Support Portal (https://go.microsoft.com/fwlink/p/?LinkId=205294). In the left pane of the SAP Support Portal, expand SAP Business Suite Applications, expand Duet Enterprise, expand Duet Enterprise 1.0, and then download the appropriate guide.

Duet Enterprise security in SharePoint Server is built on the security capabilities of SharePoint Server 2010. Along with this article, we recommend reviewing content that describes how to plan and implement general SharePoint Server security. For more information, see Security and Authentication Resource Center (https://go.microsoft.com/fwlink/p/?LinkId=196792). Much of the communication between SharePoint Server and the SAP system, together with Duet Enterprise authentication and authorization, is implemented by using Microsoft Business Connectivity Services. Therefore, we also recommend reviewing content about Microsoft Business Connectivity Services. For information about Microsoft Business Connectivity Services security and related areas, see Business Connectivity Services Resource Center (https://go.microsoft.com/fwlink/p/?LinkId=190217).

In this document:

  • thisProduct_2nd_NoVer security architecture

  • Configuring security for common thisProduct_2nd_NoVer authentication scenarios

  • Using SAP roles to grant permissions for users to access SharePoint objects

  • MOSS_2nd_ NoVer recommended security practices in thisProduct_2nd_NoVer

Duet Enterprise security architecture

In Duet Enterprise, business processes and data that is stored in the SAP system are surfaced in SharePoint Server 2010 Web sites and in Microsoft Office 2010 suites clients such as Microsoft Outlook and SharePoint Workspace. However, the user accounts that are used to access SharePoint Server 2010 and Microsoft Office 2010 suites clients cannot be used to access the information in SAP directly. The Duet Enterprise security architecture solves this issue by configuring the Microsoft Business Connectivity Services Windows Communications Foundation (WCF) connector that is included in SharePoint Server 2010. This WCF connector interacts with the Security Token Service in SharePoint Server 2010 and with SAP NetWeaver in the SAP system. The goal of this implementation is to map user identities in SharePoint Server 2010 to user accounts in the SAP system so that a user who logs on to the SharePoint Server 2010 Web site can have access to the external data that is stored in the SAP system without having to log on again in the SAP system.

The following graphic shows a high-level view of how authentication works in Duet Enterprise. It shows the steps that occur when a SharePoint user accesses SAP information from a Duet Enterprise site in SharePoint Server.

Duet Enterprise authentication

  1. The SharePoint user’s identity (a token associated with the user at logon time) is sent to the Microsoft Business Connectivity Services Windows Communication Foundation connector.

  2. The connector sends the SharePoint user’s identity to the SharePoint Security Token Service.

  3. The SharePoint Security Token Service authenticates the user and modifies the token to identify the SharePoint user to the SAP system. The SharePoint Security Token Service then returns the token to the WCF Connector.

  4. The modified token is then sent to SAP NetWeaver in a SOAP request packet.

  5. Because, during deployment, a trust relationship is created between SAP NetWeaver and the Security Token Service, SAP NetWeaver can use the token to look up the SAP user account that is mapped to the user identified in the token.

  6. The SAP user account that is mapped to the user identified in the token is returned to SAP NetWeaver.

  7. SAP NetWeaver uses the SAP user account to request access to the information in the SAP system and, if the user account is authorized to access that information, the requested information is sent to SAP NetWeaver.

  8. SAP NetWeaver sends the requested information to the Microsoft Business Connectivity Services Windows Communications Foundation (WCF) connector as a SOAP response.

  9. The Microsoft Business Connectivity Services WCF connector passes the information to the SharePoint user.

Note

Authorization in Duet Enterprise can be SAP role-based. See Using SAP roles to grant permissions for users to access SharePoint objects for more information.

The user accounts in the SAP system are at first mapped to the accounts in the SharePoint system by an SAP administrator. See the SAP Duet Enterprise Security Guide for detailed information about this process.

Tip

Common Duet Enterprise authentication scenarios

This section describes the two most common Duet Enterprise scenarios and recommended authentication configurations for each scenario. Key factors that differentiate these scenarios include the following:

  • Whether a single solution or multiple solutions will be implemented based on Duet Enterprise.

  • Whether Secure Sockets Layer is required to encrypt communications channels.

As described in the previous section, the security of Duet Enterprise spans the roles and accounts in the SAP system and in the SharePoint Server 2010 system. This integrated authentication architecture is implemented by using claims-based authentication together with Windows authentication, and these methods are required for both of the scenarios described in this section.

Important

Forms based authentication is not supported in this version of Duet Enterprise.

Tip

Most of the configuration steps that are described in these scenarios are performed while you create the Web applications that will contain the Duet Enterprise solutions. For a review of the steps to configure a Web application, see Create a Web application (SharePoint Server 2010) (https://go.microsoft.com/fwlink/p/?LinkID=202008).

Scenario: Enterprise intranet using Microsoft Windows authentication provider

This is the most typical Duet Enterprise authentication scenario. For example, an organization might maintain its employee data, such as timecard, salary, and benefits information, in a remote SAP system. All users access this data through the corporate Duet Enterprise intranet portal. All employees access the portal using the same Active Directory Domain Services provider.

This scenario could be configured in the following way:

Number of Web applications

One

Zones

One zone: Intranet

Authentication

Claims-based authentication

Claims authentication type

Windows authentication

Secure Sockets Layer?

Yes

Scenario: Two Duet Enterprise solutions in the intranet

In a large enterprise, two workgroups might share the same SAP system, for example for interacting with its product information database. Each workgroup would interact with the data through its own Duet Enterprise solution. The information in the SAP system is not sensitive in this enterprise. Therefore, to increase performance of the Duet Enterprise sites, Secure Sockets Layer is not used in this scenario.

This scenario could be configured in the following way:

Number of Web applications

Two

Zones

One zone per each Web application: Intranet

Authentication

Claims-based authentication

Claims authentication type

Windows authentication in both Web applications

Secure Sockets Layer?

No

Using SAP roles to access SharePoint objects

In the enterprise, the tasks that a user performs usually are related to that user’s role. Because of this, the determining factor on whether a user should have some level of permissions to an object often is that user’s role itself. Therefore, roles are a useful way to assign permissions to objects such as list items, Web sites, and documents.

In SAP NetWeaver, users are assigned one or more roles, such as Sales Representative, Project Manager, Executive, and Human Resources Specialist. SAP roles can be broad, such as All Sales Managers, or narrow, such as Sales Managers Eastern Region. In Duet Enterprise, these SAP roles can be used to access objects in SharePoint Server. Any object to which permissions can be applied in SharePoint Server can be assigned permissions using SAP roles. This includes objects directly related to Duet Enterprise, such as reports, external lists, and actions on external content types, and any general and securable SharePoint Server objects, such as Web sites or document libraries. Once a role is granted permissions to an object, any user that is assigned that role will then have permissions to use that object.

Users can only be assigned their roles in SAP NetWeaver. Duet Enterprise uses the Duet Enterprise Profile Synchronization Timer Job feature to bring the user role assignments from the SAP system into SharePoint Server, and it uses the Duet Enterprise Claims Provider to help manage the role-based permissions to securable objects in SharePoint Server.

During role synchronization, the set of SAP users is imported into the SharePoint User Profile Store by using Microsoft Business Connectivity Services. For each SAP user, all of the SAP roles assigned to that user are listed in the User Profile Store. Role synchronization connects from SharePoint Server to an external system on the SAP side named the “SAPUsersService.” This external system sends the user-to-roles mappings to the SharePoint User Profile Store. Role synchronization is typically done as a post-deployment step at set intervals by using the Duet Enterprise Profile Synchronization Timer Job. You can specify how often to synchronize roles and how many users to import at a time.

Once role synchronization is complete, users can assign SAP roles permissions to an object in SharePoint Server. Roles are assigned to objects by using the same people picking interfaces from which groups and individuals are selected. As shown in the graphic, the Duet Enterprise Claims Provider, using the Business Data Connectivity service, communicates with the SAP system (1 and 2) to collect and list all the SAP roles that the user can select in the People Picker (3). The user can then assign these roles to any object for which permissions can be set (4).

Using Duet Enterprise roles in the people picker

Once an SAP role is granted permissions to an object such as a list item or document, a user can be authorized to use that object based on his or her role. As shown in the graphic, when the user first logs on to a SharePoint site (1), that user is issued a SAML claims token (2) that is augmented by the Duet Enterprise Claims Provider, in communication with the User Profile Store, by adding the user’s SAP roles to the SAML token (3 and 4). SharePoint Server can then grant the user access to the object if one of the user’s roles has permissions to the object (5 and 6).

Role-based permissions in Duet Enterprise

Note

When a user’s role is changed in the SAP system, the change may take some time to be propagated to the SharePoint system. This may temporarily prevent users from being authorized based on their new roles. The process of propagating role changes can be sped up by executing an iisreset command on every front-end server in the SharePoint server farm. This will clear the cache of role information and refresh it with any updated role assignments.

Map user profile properties to SAP-roles

When SAP-roles and profiles are synchronized for Duet Enterprise, default mappings are used to determine how the properties of SharePoint Server user profiles map to the user information that is retrieved from the SAP profile store.

To map the properties of SharePoint Server user profiles, follow the procedure in the "Map user profile properties" section of Configure profile synchronization (SharePoint Server 2010). In step 2 of this procedure, select the User Profile Service application that you use for profile synchronization with the SAP environment. In step 6, select the SAP Employee BDC model (Employee.xml) for the data connection that represents the SAP external system to which you want to map the SharePoint Server property.

The following table shows an example mapping of the SAP Employee BDC model and the user profile properties.

User profile property Employee BDC model

SPS-DistinguishedName

SID

EmployeeIdDisp

Manager

PreferredName

FirstName

GivenName

LastName

FamilyName

SPS-PhoneticDisplayName

SPS-PhoneticFirstName

SPS-PhoneticLastName

WorkPhone

Iwempcom1phoneNumber

WorkEmail

Iwempcom1email

Office

Iwempadd1buildingId

SPS-JobTitle

PositionText

Department

CostCenter

UserName

PublicSiteRedirect

SPS-ProxyAddresses

SPS-SourceObjectDN

SPS-ClaimID

SPS-ClaimProviderID

SPS-ClaimProviderType

Note

Mapping user profile properties from an external SAP system is a resource intensive process. Mapping user profiles for 100,000 employees can take up to two days to complete.

Duet Enterprise is deployed on SharePoint Server farms and on SAP NetWeaver systems. This section contains general guidelines about how to configure the shared services, Web applications, rich clients, communications channels, and other elements in a SharePoint farm to improve security in Duet Enterprise.

Security Token Service

The Security Token Service authenticates SharePoint users and modifies their tokens to identify them to the SAP system (see thisProduct_2nd_NoVer security architecture). It also adds users’ roles to the tokens to support role-based authorization (see Using SAP roles to grant permissions for users to access SharePoint objects).

For performance reasons, Security Token Service tokens are cached and the cache is flushed every 24 hours. When a token is flushed from the cache, it is recreated by the Security Token Service the next time that the token is needed. The Security Token Service cache is flushed only one time per day to prevent the service from creating tokens too often, which could affect system performance.

Caching of tokens affects how frequently role information is updated in the tokens, because the role information is only added when the token is created or recreated. Therefore, there could be up to a 24 hour delay, after a user’s SAP roles change in the SAP system, for that information to be reflected in the token representing the user in SharePoint Server. During this delay, the user may not be given access to some data, documents, or sites to which he or she should have permissions, based on the user’s role(s).

It is up to Duet Enterprise administrators and solution architects to determine the best tradeoff between maintaining good Duet Enterprise performance and providing the necessary access to objects by keeping the user-to-roles mappings up to date. In general, we recommend not changing the default 24 hour caching period; notify your end users that changes to roles may take two days to propagate through the SharePoint system. However, if keeping roles information up to date is very important to your solution, you can configure the role caching interval by using Windows PowerShell.

Secure Store Service

The Secure Store Service securely stores mappings of SharePoint credentials to credentials required by external systems. In Duet Enterprise, the Secure Store Service is used only during deployment, when Microsoft Business Connectivity Services models representing SAP objects are imported into SharePoint Server using the DuetConfig.exe utility.

Before importing the BDC models, an administrator of the Secure Store Service must initialize the service by generating an encryption key. For details on how to generate the encryption key, see the "Generate a new encryption key" section of Configure the Secure Store Service (SharePoint Server 2010) (https://go.microsoft.com/fwlink/p/?LinkID=205440).

Business Data Connectivity service

In Duet Enterprise, Microsoft Business Connectivity Services provides the bridge for communications between Microsoft SharePoint Server and the SAP environment. This lets users connect to and interact with SAP objects such as sales contacts, tasks, and customers. Objects are modeled in the Microsoft Business Connectivity Services metadata store, and permissions in Microsoft Business Connectivity Services associate individual accounts, group accounts, or claims with one or more permission levels on an object in the metadata store. For more information about how permissions can be set on models, external systems, external content types, methods, and method instances in the metadata store, see Business Connectivity Services security overview (SharePoint Server 2010) (https://go.microsoft.com/fwlink/p/?LinkId=205679).

As described in Using SAP roles to grant permissions for users to access SharePoint objects, Duet Enterprise provides additional permissions functionality. SAP roles can be used to grant permissions to access objects in SharePoint Server, and any object to which permissions can be applied in SharePoint Server can be secured by using SAP roles.

You can use SAP roles to help implement security for the SAP objects that are modeled in the Microsoft Business Connectivity Services. By doing this, you help ensure that users who do not have the required roles will not have access to objects that are not relevant to their responsibilities. For example, all external content types that define customers can be configured to be accessed and operated on only by the SAP_SALES_REP role.

Warning

Some models that are included in Duet Enterprise have specific permissions requirements and cannot be made secure with roles. For example, in the SAPRoles model, which is used in Duet Enterprise role synchronization, the special group All Authenticated Users must be given Execute permissions to the method instances of the external content types in the SAPRoles model.

User Profile Service

Duet Enterprise users and their roles are synchronized with the SAP system and stored in the SharePoint Server User Profile Service’s profile store. The process of synchronizing the users to roles mappings between Duet Enterprise and the SAP system is initiated in the DuetConfig utility. Before running DuetConfig to start this task, the farm administrator running DuetConfig must be given full control permissions to the User Profile Service.

In some Duet Enterprise deployments, a centralized User Profile Service in one SharePoint farm will provide role synchronization for multiple other SharePoint farms that host Duet Enterprise solutions. In these “federated” configurations, there will be a Security Token Service in each farm that uses the centralized User Profile Service. For role synchronization to work from a farm that uses a centralized User Profile Service, the application pool account of that farm’s Security Token Service must be given read permissions to the centralized User Profile Service.

Office client applications

Duet Enterprise authentication from Office client applications requires interactions with the Security Token Service running in SharePoint Server. Communication between Office client applications and SharePoint Server is therefore necessary even when connecting to the external SAP system from Office client applications. Because Duet Enterprise uses Windows authentication, communications between Office client applications and SharePoint Server can be implemented securely using http:// addresses. They do not require https:// addresses.

To support offline features of SharePoint Server, communications between Office client applications and the SAP system are also required. (These connections are defined in the models that provide access to the external data available in the SAP system.) To help ensure security regarding access to the SAP system, communication between Office clients and the SAP system should be implemented by using Secure Sockets Layer and https:// addresses.

Report Routing

The Duet Enterprise reporting feature combines SAP report-generation capabilities with SharePoint Server document management capabilities. It enables end users to request SAP reports from within a SharePoint Server site. These reports are generated on the SAP system and correctly routed and stored in SharePoint Server document libraries so that authorized users can view them. A solution based on Duet Enterprise can integrate reporting into as many sites as are needed. All reports for the sites in a particular Web application are routed to the correct libraries in that Web application by the OBAFileReceiver Web service, which is connected to that Web application when the Web application is configured for reporting.

As described in Configure reporting (https://go.microsoft.com/fwlink/p/?LinkId=205681), you should configure any Web application hosting reports by extending the Web application to an additional zone in which the service can run securely. This zone must have the following characteristics:

  • It must use Secure Sockets Layer (SSL)

  • It must use claims authentication

  • It must use Windows authentication and Basic authentication

  • It must be bound to a certificate that is trusted by the SAP system

Role based permissions

As described in Using SAP roles to access to SharePoint objects, Duet Enterprise uses the Duet Enterprise Claims Provider to help manage role-based permissions to securable objects in SharePoint Server. When a claims provider is used in a solution, it increases the time required to perform certain operations. To promote the most efficient performance of the Duet Enterprise Claims Provider, we recommend that you do the following:

  1. Configure the Duet Enterprise Claims Provider so that it is not used by default. When you do this, Web applications that are not related to Duet Enterprise will not query the Duet Enterprise Claims Provider. To configure the Claims Provider so that it is not used by default, use the following Windows PowerShell script:

    $myClaimPrMgr = Get-SPClaimProviderManager
$TCP = $myClaimPrMgr.GetClaimProvider("DuetEnterpriseClaimsProvider")
$TCP.IsUsedByDefault = False
$myClaimPrMgr.Update()

  2. Associate the Duet Enterprise Claims Provider with each Web application that is part of your Duet Enterprise solution. To do this, use the following Windows PowerShell script for each Web application that is part of your solution:

    $web = Get-SPWebApplication "http://WebApplication"
$iis = $web.GetIisSettingsWithFallback([Microsoft.SharePoint.Administration.SPUrlZone]::Default)
$iis.ClaimsProviders.Add("DuetEnterpriseClaimsProvider")
$web.Update()

    In the previous sample script, replace "http://WebApplication" with the URL of Web application.

    To remove a Web application’s association with the Duet Enterprise Claims Provider, use the following script:

    $web = Get-SPWebApplication "http://Webapplication"
$iis = $web.GetIisSettingsWithFallback([Microsoft.SharePoint.Administration.SPUrlZone]::Default)
$iis.ClaimsProviders.Remove("DuetEnterpriseClaimsProvider")
$web.Update()

    In the previous sample script, replace "http://Webapplication" with the URL of the Web application.

Important

In SAP NetWeaver, the SharePoint Timer Job Domain Account should be mapped to an SAP user who has permissions to query for user roles assignments.