High Level Summary
Accessing external systems from SharePoint portals is a typical integration scenario. One reality that has not changed is that there are three basic components to any interoperability scheme.
- Communication–You must be able to connect and communicate with the foreign system, either through code or through infrastructure.
- Identity Management–You must have some way to authenticate users against the foreign system.
- Composition–You must be able to assemble discrete pieces of data (from tables, function calls, and so on) into an entity that is meaningful and useful to business users.
There are challenges in all three of these activities, regardless of what you are connecting.
The architecture tackles the four issues elegantly. WCF provides the communication. Single Sign On provides the Identity management. Business data catalog allows different ways to compose such as DataViewWebPart, BDC object model, search and out-of-box BDC web parts.
Comparing with directly accessing WCF web service, my favorite argument to support this architecture is that BDC is a layer of security boundary in addition to its support to search. BDC allows you to authorize the access to BDC entities through Shared Service web pages. With direct WCF access, there is no easy way to achieve this level of seamless integration and flexibility to control the authorization.
Another advantage of this architecture is to let BDC access external data through SSO, which allows the management of identities in SharePoint central admin web pages. Invoking WCF or Web Service directly from code will run into the famous double hop issue in a distributed environment unless you hard code the user credentials. The matter will be even more complicated if you use SharePoint Form Authentication. BDC has very nice integration with SSO so it is a very nature approach to marry those two technologies together for accessing external data.
Implementation Details
Notice, it is not a step by step tutorial. Instead, it covers important ideas and possible catches during implementation.
Tools
- Visual Studio 2008 for WCF development
- Microsoft Application Definition Designer for BDC definition.
- Microsoft MOSS server for SSO and BDC configuration
Ideas/Catches
Use BDC to control the authorization. In the home page of the ShareService administration web site, you will see the “Business data catalog permission” at the bottom-right corner as the following
Use WCF to encapsulate your external system. BDC supports “basichttpbinding” only. The following is a sample web.config. Here is one of the biggest catch. If running the WCF inside VS2008, use “NTLM”. After deploying the WCF to production, use “Windows”. It appears that VS2008 debug web server has different behavior in terms of WCF authentication. Also, in VS2008, you cannot test WCF authorization through [PrincipalPermission(SecurityAction.Demand, Name = “”)], it won’t work.
<service behaviorConfiguration="WindowsAuthorizationBehavior"
name="BDCContractImplementation">
<endpoint address=""
binding="basicHttpBinding"
bindingConfiguration="WindowsAuthenticationBinding"
contract="IBDCContract">
<identity>
<dns value="host" />
</identity>
</endpoint>
</service>
<behaviors>
<serviceBehaviors>
<behavior name="WindowsAuthorizationBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
<serviceCredentials>
<windowsAuthentication includeWindowsGroups="true" allowAnonymousLogons="false" />
</serviceCredentials>
<serviceAuthorization principalPermissionMode="UseWindowsGroups"
impersonateCallerForAllOperations="false" />
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<basicHttpBinding>
<binding name="WindowsAuthenticationBinding"
maxBufferSize="2147483647"
maxReceivedMessageSize="2147483647">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Ntlm"/> <!-- works in VS2008 debug -->
<!--<transport clientCredentialType="Windows" /> --> <!-- works after deploying to IIS -->
</security>
</binding>
</basicHttpBinding>
</bindings>
The catch of the return value from IDEnumerator in BDC. If the ID is of type string, you can not return list<string> from IDEnumerator. You must implement a simple class to encapsulate the ID; otherwise, for some reason, Microsoft Application Definition Designer won’t able to handle the method
/* The small class to encapsulate the string */
[DataContract]
public class MeetingID
{
[DataMember]
public string MeetingIDStr { get; set; }
}
[ServiceContract]
public interface IMeetingBDC
{
[OperationContract]
List<Meeting> GetAllMeetings(string filter);
[OperationContract]
Meeting GetMeetingSpecificFinder(string meetingId);
[OperationContract] /* the signature for IDEnumerator */
List<MeetingID> GetMeetingIdEnumerator();
}
BDC configuration using SSO. Copy paste and modify the following code:
<LobSystemInstance Name="BDCMeeting_Instance">
<Properties>
<Property Name="LobSystemName" Type="System.String">LobMeeting</Property>
<Property Name="WebServiceAuthenticationMode" Type="Microsoft.Office.Server.ApplicationRegistry.SystemSpecific.WebService.HttpAuthenticationMode">WindowsCredentials</Property>
<Property Name="SsoProviderImplementation" Type="System.String">Microsoft.SharePoint.Portal.SingleSignon.SpsSsoProvider, Microsoft.SharePoint.Portal.SingleSignon, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c</Property>
<Property Name="WebServiceSsoApplicationId" Type="System.String">your_sso_application_id</Property>
</Properties>
</LobSystemInstance>
No comments:
Post a Comment