For what all purpose does BizTalk use SSO? I have read here that "BizTalk Server uses SSO to help secure information for the receive locations". Is that it? Doesn't it also store information for other BizTalk artefacts' also?

Hi Dipti,

 SSO mainly deals/stores with configuration information which include receive location and receive handler.

Below are services from SSO

1. Password synchronization to simplify administration
2. User account and password mapping & caching
3. SSO to multiple Windows domain &  host security systems

Information about the BizTalk artifacts is stored in Management database.

You can read more here and here for more in

Hi Dipti,

Below are features provided by SSO in BizTalk ,

 1)SSO is used as config  to securely store BizTalk configuration information in encrypted form.
(BizTalk itself uses this feature to store all BizTalk configuration information)

2)To map windows credentials to non-windows/back-end credentials

Thanks

Abhishek

• Proposed as answer by Maheshkumar S Tiwari Friday, January 10, 2014 10:06 AM

Hi Dipti,

Below are features provided by SSO in BizTalk ,

 1)SSO is used as config  to securely store BizTalk configuration information in encrypted form.
(BizTalk itself uses this feature to store all BizTalk configuration information)

2)To map windows credentials to non-windows/back-end credentials

Thanks

Abhishek

• Proposed as answer by Maheshkumar S Tiwari Friday, January 10, 2014 10:06 AM

To answer your specific question, yes.

The only way BizTalk out of the box uses SSO is to store Receive Location/Send Port configurations that contain passwords. This is as an alternative to storing them in clear text in the Management Database.

All other configuration data is stored in the Management Database, BizTalkMgmtDb.

As EntSSO is included with BizTalk Server, it provides an excellent place to store many kinds of data.

• Proposed as answer by Maheshkumar S Tiwari Friday, January 10, 2014 10:07 AM

To answer your specific question, yes.

The only way BizTalk out of the box uses SSO is to store Receive Location/Send Port configurations that contain passwords. This is as an alternative to storing them in clear text in the Management Database.

All other configuration data is stored in the Management Database, BizTalkMgmtDb.

As EntSSO is included with BizTalk Server, it provides an excellent place to store many kinds of data.

• Proposed as answer by Maheshkumar S Tiwari Friday, January 10, 2014 10:07 AM
• Marked as answer by Dipti S 2 hours 34 minutes ago

To answer your specific question, yes.

The only way BizTalk out of the box uses SSO is to store Receive Location/Send Port configurations that contain passwords. This is as an alternative to storing them in clear text in the Management Database.

All other configuration data is stored in the Management Database, BizTalkMgmtDb.

As EntSSO is included with BizTalk Server, it provides an excellent place to store many kinds of data.

• Proposed as answer by Maheshkumar S Tiwari Friday, January 10, 2014 10:07 AM
• Marked as answer by Dipti S Tuesday, January 14, 2014 8:53 AM

SSO can be used to store single sign-on credentials, but you can basically store any key/value pair in it.

If you use the SSO MMC SnapIn you can add easily key/values to it.

Using code from this blog, you can read values from SSO inside your BizTalk application (or any other application).

my 5c

You could ask why BizTalk store someone credentials? Kind of unusual. It is not the purpose of the integration system, to manage credentials, let's AD deal with it, right?

But... The BizTalk Server does not just route data between system. It also bridge data formats and protocols.

Say, you want to receive a message transform it and send it outside. 

Now the received and send messages are encrypted (and/or signed) with completely different credentials. You HAVE TO decode the received message, make some data transformations in unencrypted form, of course, then encode sent message. You use different credentials for receive and sent, for different producers and consumers. So you HAVE TO manage those credentials: store them and use them. And ESSO was created...

Microsoft decided to use it as the part of BizTalk Server, but technically the ESSO service is an independent se

Thanks all. My question is specific to what are the artefacts' that SSO db stores when we don't explicitly do any programming to use SSO. i.e. only BTS internal implementation.

So, BTS stores Rcv Location and Send port (if it contains pwd). Correct?

This also discusses it: http://stackoverflow.com/questions/1772663/whats-entsso-for-in-biztalk-server

...

As EntSSO is included with BizTalk Server, it provides an excellent place to store many kinds of data.

Sorry for off-topic.

One of my client prohibited to use SSO for storing any configuration data. They argument, you can unintentionally broke something by writing/reading to/from it. Then the BTS is broken. The opposite argument is the Microsoft intentionally created API to do such things. 

What experience do you, guys, have with this?

Thanks all. My question is specific to what are the artefacts' that SSO db stores when we don't explicitly do any programming to use SSO. i.e. only BTS internal implementation.

So, BTS stores Rcv Location and Send port (if it contains pwd). Correct?

It stores also some application data and auditing data, for example, who and when deleted the applications.

Thanks all. My question is specific to what are the artefacts' that SSO db stores when we don't explicitly do any programming to use SSO. i.e. only BTS internal implementation.

So, BTS stores Rcv Location and Send port (if it contains pwd). Correct?

Correct.  Only the internal implementation of some Adapters (never had occasion to find out exactly which ones) use SSO.

The same facility is equally available to ISV Adapter developers and is/should be used if there are config properties that should not be stored in the clear.

One of my client prohibited to use SSO for storing any configuration data. They argument, you can unintentionally broke something by writing/reading to/from it. Then the BTS is broken. The opposite argument is the Microsoft intentionally created API to do such things. 

Sounds rather arbitrary to me.  You can read/write to BizTalkMgmtDb much easier and really break BizTalk.

One of my client prohibited to use SSO for storing any configuration data. They argument, you can unintentionally broke something by writing/reading to/from it. Then the BTS is broken. The opposite argument is the Microsoft intentionally created API to do such things. 

Sounds rather arbitrary to me.  You can read/write to BizTalkMgmtDb much easier and really break BizTalk.

Yeah, a good point.

They argue about special purpose of SSO and how hard is to restore in case of crash.