Recently at my work we’ve started using SSO Affiliate Applications to store credentials for Receive Locations and Send Ports to avoid either having the credentials in the Bindings (which is insecure) or having to re-enter the credentials after each release (which causes releases to take too long). I won’t go into details how we do that in this post, however as part of documenting this ability I went through all the adapters to see which could use SSO Affiliate Applications and which couldn’t.

For clarity here is what the different columns and the values mean.

  • The Use SSO column indicates if you can tick a check or radio box in the Receive Location to create a SSO ticket from the account used to send a message to the Receive Location so that ticket could be used on the Send port to map the users via a SSO Affiliate Application
  • The Use SSO Affiliate column indicates if it can be configured to use a SSO Affiliate Application to connect using the credentials stored there instead entering the credentials in the port.
  • The ACS / SAS column if it can be configured to use a SSO Affiliate Application for holding the keys and secrets.
  • The Proxy column if the proxy credentials can be configured to use a SSO Affiliate Application.
  • Endpoint Behaviour if it may be possible to write a Endpoint Behaviour that you can configure on the port that could use credentials from a SSO Affiliate Application
  • Yes = It is possible
    No = Not possible
    = Not applicable
    in WCF-Custom = that it is not possible in the adapter but may be possible in WCF-Custom with that binding.
Receive Adapter Use SSO SSO Affiliate ACS/ SAS Proxy  Endpoint Behaviour
File No
FTP Yes No
HTTP Yes
MQSeries No
MSMQ No No
POP3 No
SB-Messaging No (ACS & SAS)
SFTP No No
SOAP Yes
SQL No
WCF-BasicHttp Yes in WCF-Custom
WCF-BasicHttpRelay No No (ACS) No
WCF-Custom Yes Yes Yes
WCF-CustomIsolated Yes Yes
WCF-NetMsmq in WCF-Custom
WCF-NetNamedPipe Yes in WCF-Custom
WCF-NetTcp Yes in WCF-Custom
WCF-NetTcpRelay No No (ACS)
WCF-OracleDB Yes Yes Yes
WCF-OracleEBS Yes Yes Yes
WCF-SQL Yes Yes Yes
WCF-WebHttp Yes Yes
WCF-WSHttp Yes in WCF-Custom
Windows Sharepoint Server No

 

Send Adapter SSO Affiliate ACS/ SAS Proxy Endpoint Behaviour
File No
FTP Yes No
HTTP Yes No
MQSeries Yes
MSMQ No
SB-Messaging No (ACS & SAS)
SFTP No No
SMTP No
SOAP Yes No
SQL No
WCF-BasicHttp Yes No (ACS) No in WCF-Custom
WCF-BasicHttpRelay Yes No (ACS) No No
WCF-Custom Yes No Yes
WCF-NetMsmq Yes
WCF-NetNamedPipe
WCF-NetTcp Yes in WCF-Custom
WCF-NetTcpRelay Yes No (ACS) No
WCF-OracleDB Yes No Yes
WCF-OracleEBS Yes No Yes
WCF-SQL Yes No Yes
WCF-WebHttp Yes No (ACS) No Yes
WCF-WSHttp Yes No in WCF-Custom
WindowsSharepointServer No

Conclusions:

You can’t use SSO Affiliates for any Proxy credentials, ACS or SAS credentials, I think this is a major oversight.  Also not having the setting in the new SFTP is a real pity.  It would also be nice to have the ability to use SSO Affiliate for some of the other older adapters.

See also: BizTalk Server 2013 R2: Adapters without Single Sign-On Capability by Peter Lindgren

Note: This was originally posted as an Answer on How can I set SB-Messaging adapter credentials securely?  and has since also been included in the article BizTalk Server 2013 R2: Adapters without Single Sign-On Capability

Advertisements