Inbound trading partner and document security
Hello all!
Please allow me to introduce myself, my name is Tony Bernard and I am a Senior Program Manager on the BizTalk Server team. I am taking over for Suren Machiraju who, as relayed in his final post, has moved on to new and exciting opportunities elsewhere within Microsoft.
I want to take this opportunity to thank Suren for his many years of dedication and leadership on the B2B team!
In this posting I thought I would share a little trick for implementing trading partner and document security on inbound transmissions. By default, the EDI implementation in BizTalk 2006 R2 (which I will simply refer to as R2 for the remainder of this posting) will accept and validate all inbound interchanges as long as the proper schema is deployed and there is a receive location with either the EdiReceive or AS2EdiReceive pipeline specified. I'll call this approach an 'implicit accept' approach since all transmissions are by default processed assuming the appropriate artifacts are deployed.
So what do you do if you want to take an 'implicit deny' approach to processing interchanges? And how would you do that at both a trading partner level (i.e. only allow interchanges from specific partners) and at a document level (i.e. only allow certain documents from approved trading partners)?
Receive Port Authentication
One way to implement partner level security is to leverage the Authentication settings on the Receive Port. In R2 the EDI receive pipeline will compare security and authorization fields in the incoming interchange envelope with those specified in the party. If valid, the interchange will be accepted and processed. If not, the interchange will be handled according to the settings in the Authentication section on the General page of the Receive Port properties.
Partner Level Security
But what if you aren't using the security or authentication settings specified in your EDI standard (which many, arguably most, don't) or for some other reason don't want to turn on Receive Port Authentication? Well that's where our little trick comes in. There is a property on the EDIFACT and X12 Interchange Processing Properties pages of the EDI Global Properties called Target namespace. The primary intent of the property is to facilitate the 'implicit accept' behavior mentioned above by ensuring that all inbound interchanges would get assigned a valid schema namespace. However, the same field can be used to implement 'implicit deny' behavior as well. By setting this field to a dummy or 'dead letter' namespace (i.e. one in which there are no schemas) by default all inbound interchanges will be assigned that namespace unless they are successfully associated with a specific party agreement by the EDI receive pipeline. They will then be suspended by BizTalk due to a missing or invalid schema. Therefore, the only documents that will make it through will be ones which have a party agreement implemented.
Document Level Security
Now that we have discussed partner level security, let's talk about how to implement document level security. The scenario here is that you've implemented a partner for certain document types (say purchase orders), but don't want to accept other documents (say advanced ship notices or invoices) that may still be in testing. The approach is very similar to that for partner level security in that it leverages namespaces. However, for this trick we will work within the party-specific settings for that trading partner. As in the EDI Global Properties, there is a property where a default namespace for the party can be specified. This property is labeled Default Target namespace and can be found on the EDIFACT and X12 Interchange Processing Properties pages of the EDI Properties for a given party. Again, the primary intent of this setting is to ensure that all documents for this party get assigned a valid namespace. However, by leverage this property in conjunction with the Enable custom transaction set definitions grid just below it you can implement the same behavior with individual document types as you did with partners as described above. Simply set the Default Target namespace to a dummy or 'dead letter' namespace and then create entries in the grid below for the documents that you want to allow to be processed. This is analogous to creating a 'white list' for spam filtering. Documents that don't match the ones on that list will be assigned the default (i.e. dummy) namespace and will be suspended.
So there you have it. Two techniques to enhance the security of your R2-based EDI solution. That's all for now, but as always, feel free to keep the questions, comments and suggestions coming.
Cheers,
Tony
Comments
Anonymous
April 13, 2007
Good feature, thanks! I need this in everyday routine. (Use it now with Covast but want to move to EDI R2.) I'd prefer to call it as "spam" and explicitly visually design it as a Spam. It's not many sense in suspending such EDI docs. I'd prefer to move them in "Spam" folder or something else but do not save this garbage in the MessageBox. (or give me choice: suspend or move to.. or delete (yes! it is the real choice!)). Regards, Leonid Ganeline BizTalk Solution DeveloperAnonymous
August 03, 2007
Hello, My name is Sudhakar, I am working on Biztalk 2006 . I have a question , Is Base EDI adapter in BizTalk 2006 support x-12 4030 version EDI documents? Thank you.