Некоторые Receive Adapters (HTTP и SOAP, например) могут вызвать ISSOTicket.IssueTicket() и, в случае успеха, записать результат в (promoted) context property "SSOTicket". Самое важное в этом то, что делается это для user'a, успешно прошедшего authentication в Receive Port. Сам этот user ( в форме domainName\userName ) записывается в property "WindowsUser" .
Как именно осуществить authentication, решает сам адаптер, а в случае SOAP или HTTP, оба они используют для этих целей свой Isolated Host, т.е. host, кот. бежит в IIS, т.е. его Windows Authentication. (IIS7 по умолчанию устанавливается без Windows Authentication, соответствующий модуль должен быть добавлен дополнительно прежде чем администратор или радивый программист получат возможность разумно убрать Anonymous Authentication с IIS Application).
Если конфигурация адаптера включает вызов IssueITicket, но без аутентикации, то "SSOTciket" context property сгенерирован не будет, a property "WindowsUser" будет содержать пустое значение (хотя сам этот property будет записан в контекст сообщения).
Все это делается для того, чтобы соответствующий Send Adapter мог вызвать RedeemTicket(), и тем самым получить искомые внешние mappings для исходного user'a. Понятно, поэтому, что необходимым условием для этого сценария будет тот факт, что оба API - IssueTicket и RedeemTicket - вызываются для одного и того же user'a. Собствеено, этому и служит упомянутый property "WindowsUser". Без него вызов обоих ISSOTicket-методов лишается смысла, и поэтому вообще не стоит пробовать применять SSO без authentication.
SSO устанавливается по умолчанию без поддержки tickets. ssomanage.exe или MMC 3.0 решают и этот вопрос.
При этом я не имею в виду authentication, запрашиваемую на уровне Receive Port, а механизм, с помощью которого сам адаптер может провести authentication, как "Windows Authentication" в случае SOAP/HTTP и IIS.
Сообщение, кот. было опубликовано в MessageBox с установленными "SSOTicket" и "WindowsUser" может попасть оттуда или в оркестрацию, или в Send Port. В случае оркестрации, эти context properties должны быть скопированы из поступившего сообщения в то, кот. будет послано в Orchestartion Send Port, например, так (Message Assignment Shape):
msgOut(BTS.SSOTicket) = msgIn(BTS.SSOTicket);
msgOut(Microsoft.BizTalk.XLANGs.BTXEngine.OriginatorSID) = msgIn(Microsoft.BizTalk.XLANGs.BTXEngine.OriginatorSID);
Второй оператор в этой записи гарантирует, что обсуждаемый RedeemTicket метод будет вызван для того же user'a, для которого раньше вызывался IssueTicket. В случае, если сообщение попадает в SendPort, этого гарантировать нельзя, что и приводит к подобным ошибкам.
Все сказанное относится только к тем адаптерам и оркестрациям, кот. работают под Trusted Host. И наконец, напоследок, еше одно замечание о Send Adapters : помните о первом параметре в RedeemTicket! Это ваш affiliate application. Sic! В конце концов, мы ведь хотели всего-навсего перевести credentials вызывающего user'a в external credentials. Именно affiliate application и хранит этот mapping. Properies, доступные аднинистартору Send Adapter'a при конфигурации Send Port'a должны давать возможность выбрать из списка установленных affiliate applications, тем более что BAF поможет в этом - см. baf:SSOList.