2007/9/7, Assaf Arkin <[EMAIL PROTECTED]>: > Well, it is a header that's only applicable to some protocol, so it's no > longer utilizing the WSDL protocol abstraction, it fixes the abstract > message usage to the actual protocol bindings. And you need as many of > these as there are authentication protocols. And it is holding on to > username/password, one of which might change before the process completes. > > The proper way would be to add an authentication context that's separate > from the message definition, but can be carried across operations, and let > the protocol binding deal with mapping it to the details of each protocol.
> I don't think extending PartnerLink is enough, that would only allow you to > always authenticate as the same subject against the same service. It's > quite common to expect authorization to change, e.g. depending on who > started the process. But wouldn't this imply to take another "role" in terms of partnerLink roles? e.g. when I'm logged in as "admin" I'm taking another role as when I was logged in as "johndoe", normal customer. And even such a distinction cannot be modeled via 2 partnerLinks, one could <assign> different credentials to a partnerLink. Or am I wrong? Cheers, Tammo -- Tammo van Lessen - [EMAIL PROTECTED] - http://www.taval.de
