1

I have a BizTalk messaging-only interchange that uses the legacy HTTP adapter running in an isolated host on the receive end, which routes directly to a send port using the WCF-OracleDB adapter. The Send port is configured to retrieve credentials from SSO. The HTTP adapter is configured to use SSO and issues an SSO ticket in the context of the isolated host user.

When the send port activates, it logs the following message to the event log and stops:

Validation of the ticket failed. The sender name must match that of the ticket issuer.
 Application Name: (affiliate application name)
 Ticket Issued By: (in-process account name)
 Sender Name: (isolated host account name)

The affiliate configuration is correct according to all the documentation I can find:

  • Both accounts are in the domain group specified as the affiliate's Application Users property
  • Both accounts have mappings in the affiliate to the desired external credential. I've tried a user-based affiliate, which won't allow more than one mapping to the same external credential, with both accounts as the host credential one at a time, and a group-based affiliate, with both accounts with a mapping to the same external credential simultaneously.

I have found this documentation, that suggests that in order to use SSO tickets, the hosts must be trusted: https://msdn.microsoft.com/en-us/library/bb899011.aspx

I have done this, which makes no difference.

I have also unchecked the 'validate tickets' option in the SSO Administration console for this affiliate, which also makes no difference.

What do I have to do to make this work?

Tom W
  • 5,108
  • 4
  • 30
  • 52

1 Answers1

0

The issue is that the user that is stamped on the message is that of the receive port (the Isolated Host User), but you are issuing the SSO Ticket on your Send Port, which will then issue the ticket to the In Process Host users.

What you need to do is to issue the SSO Ticket in the Receive Location so that the Ticket matches the user. If both your Receive Location & Send Port are on the same host you can issue the SSO Ticket in your Send Port.

No you do not need to mark your Host as trusted. You only need to do this if you want to pass the credentials of the caller from the Receive Location through to the Send Port (in which case you can tick it in the receive location (if available) to issue a SSO to that user in the Port).

Dijkgraaf
  • 11,049
  • 17
  • 42
  • 54
  • That's an annoying tight coupling requirement. The receive location shouldn't need to know anything about the outbound transport - and if I have a different account running the receive host, shouldn't it be the account running the send host that requires SSO permissions if it's the send port using SSO, not an unrelated receive host? Isn't this what the OriginatorSID property is for? If I overwrite that, shouldn't this tell the SSO system what my intent is? And what if the receive adapter doesn't support SSO tickets? What are you supposed to do then? Thanks for your answer. – Tom W Feb 23 '17 at 15:45
  • @TomW That is because we are actually using the SSO differently from what was intended (to pass the credentials from the caller through and to optionally map it to another set of credentials). Yes, there are various adapters that don't support it see https://stackoverflow.com/questions/37155838/how-can-i-set-sb-messaging-adapter-credentials-securely/37174322#37174322 or https://cdijkgraaf.wordpress.com/2016/08/30/biztalk-sso-sso-affiliate-settings/ However in this situation you can add the SSO ticket in the Receive Pipeline, so it doesn't matter what the adapter is. – Dijkgraaf Feb 23 '17 at 20:28
  • As per your advice I now have the HTTP receive location issuing a ticket, which is successfully redeemed. So far so good. However the other locations run under the in-process account and it is not possible to create more than one user mapping for the same external credentials. I could create a group affiliate (rather than a user affiliate) but the isolated host account and the in-process host account don't share any groups! Surely there must be a way for this to **just work**. I am at my wits end with this. – Tom W Feb 24 '17 at 13:53
  • @TomW Can you create another set of credentials for the OracleDB so that they use different credentials? I take it your solution is messaging only? The other option is to put an Orchestration in, that way the message is under the in-process host. – Dijkgraaf Feb 25 '17 at 01:29
  • I could, but that is polluting the destination system with a BizTalk idiosyncrasy it has no need for. The approach we are now trying is creating a group-based Affiliate with a new group that contains both the isolated and the in-process host accounts. And it **still** doesn't work. How could SSO credentials ever work, if it won't accept a ticket from an issuer that's different from the host account? Based on its original intended usage, the issuer of the ticket should be the *client* user, which would ALWAYS be different. – Tom W Mar 08 '17 at 15:01
  • @TomW For the original purpose the ticket would be issues against the client user, you then can map multiple client users to the same SSO Affiliate Application user. Have you tried mapping both the inprocess & isolated host to the same creds? – Dijkgraaf Mar 08 '17 at 20:14
  • The SSO administration console won't allow it. I thought the expected alternative would be to use a group-based affiliate and map the group that both host users exist in to a single destination credential but that doesn't work either - in that it doesn't change the behaviour in the slightest. – Tom W Mar 08 '17 at 21:07
  • @TomW You should be able to map multiple credentials to the same SSO Affiliate (I think you must be trying to set up multiple SSO Affiliates with the same creds, that is not allowed) – Dijkgraaf Mar 08 '17 at 21:09
  • Nope, definitely not. I can screenshot the behaviour when I'm next at a development machine. – Tom W Mar 08 '17 at 21:13
  • Aha. A user-based affiliate application won't let you add more than one user account mapping to the same external credential, but a group-based affiliate will. Nevertheless, this doesn't make any difference either, I still get a transmission failure and an event log message `Validation of the ticket failed. The sender name must match that of the ticket issuer.` – Tom W Mar 09 '17 at 13:29
  • Please see my edit regarding the abandonment of the custom ticket issuing code, which should not be necessary. This is now a 'normal' port-to-port SSO scenario which should just work as described, and I can't see why it won't do what the documentation says it does. – Tom W Mar 09 '17 at 14:04
  • 1
    Got it. I misunderstood your statement of not needing hosts that are authorisation trusted (which I believe you meant 'when issuing in the send port', and reverted this setting back to where it was. When the ticket is issued on the *receive* port it *is* required. – Tom W Mar 11 '17 at 10:10
  • @TomW I've raised this as an Issue on Github. https://github.com/mbrimble/brepipelineframework/issues/3 – Dijkgraaf Oct 04 '17 at 03:00