Hi,
As far as I understand, SOAP Adapter redeems SSO ticket passed in message
context. In turn, redeem will succeed only for authenticated calls. If so,
why NTLM authentication method disables SSO for SOAP Adapter? The same
question applies to Kerberos authentication for HTTP Adapter and 'Integrated
authentication' method for WSE Adapter.
Thanks in advance.

[ Post a follow-up to this message ]

Because SSO cannot be used to connect one NT account to another NT
ccount  - that would be a type of two machine hop that just isnt allowed
from a security POV (might be a licensing issue as well).

SSO is meant to take incoming NT crednetials and translate them into NON-NT
credentials.

--
Jon Flanders [DevelopMentor]
http://staff.develop.com/jfland/
http://www.develop.com/courses/biztalk
"oleg_kleyman" <olegkleyman@discussions.microsoft.com> wrote in message
news:4FBA9647-C848-480D-9776-98149C39F486@microsoft.com...
> Hi,
> As far as I understand, SOAP Adapter redeems SSO ticket passed in message
> context. In turn, redeem will succeed only for authenticated calls. If so,
> why NTLM authentication method disables SSO for SOAP Adapter? The same
> question applies to Kerberos authentication for HTTP Adapter and
> 'Integrated
> authentication' method for WSE Adapter.
> Thanks in advance.
>

[ Post a follow-up to this message ]

All mentioned authentication methods - NTLM, Kebreros etc. may be used to
validate Windows user against some NT Authority. What I'm trying to
understand is why the validation performed via NTLM and Kerberos is not good
for SSO ticket's redeeming. It's clear that such redeeming is used to map
windows user to external (not Windows) credentials.

"Jon Flanders[DevelopMentor]" wrote:

> Because SSO cannot be used to connect one NT account to another NT
> ccount  - that would be a type of two machine hop that just isnt allowed
> from a security POV (might be a licensing issue as well).
>
> SSO is meant to take incoming NT crednetials and translate them into NON-N
T
> credentials.
>
> --
> Jon Flanders [DevelopMentor]
> http://staff.develop.com/jfland/
> http://www.develop.com/courses/biztalk
> "oleg_kleyman" <olegkleyman@discussions.microsoft.com> wrote in message
> news:4FBA9647-C848-480D-9776-98149C39F486@microsoft.com... 
>
>
>

[ Post a follow-up to this message ]

Hi Oleg,

> All mentioned authentication methods - NTLM, Kebreros etc. may be used to
> validate Windows user against some NT Authority. What I'm trying to
> understand is why the validation performed via NTLM and Kerberos is not
good
> for SSO ticket's redeeming. It's clear that such redeeming is used to map
> windows user to external (not Windows) credentials.

That's a good question. My guess is that similar how Jon mentions, the idea
here is that you'd only use NTLM and Kerberos if you wanted to logon to the
remote server using the identity of the running BizTalk Application Host,
however, that, by itself, doesn't seem very useful (particularly given that
the requirement to use integrated security is imposed by the server side,
not the biztalk side, usually).

It might be, however, a very simple technological problem... If the HTTP
adapter uses the .NET libraries for this, I believe the support in them for
integrated security doesn't allow you to use NTLM/Kerberos authentication
with alternate credentials [1](and only those of the running thread,
instead), but I don't know the implementation details here, so I might be
wrong.

[1] This would be a limitation of the .NET implementation, which probabl
y
uses SSPI underneath for the integrated authentication, and SSPI most
certainly allows you to use alternate credentials.

--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/

[ Post a follow-up to this message ]