2007/9/10, Assaf Arkin <[EMAIL PROTECTED]>:
> On 9/9/07, Tammo van Lessen <[EMAIL PROTECTED]> wrote:
> >
> > 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?
>
> partnerLink roles are strictly invoker or invokee. whether you're admin or
> johndoe, you are still going to interact through a limited set of operations
> available on the interface (portType), and the partnerLink role tells you
> which interface it will be,
Hm, sure. My examples was a bit misleading. Better would have been:
UserPortType and AdminPortType. The thing I wanted to point out was
that at least for webapps the capabillities of a service often change
depending on the credentials a user has. Translated to Web Services
this would result in different interfaces/portTypes, so it would make
sense to model it in BPEL as different partnerLinks (adminPL, userPL)
which might be bound to the same EPR.
> what we need is a way to pass those principles from one invoke to another,
> so the process can be invoked on behalf of some principle (maybe admin,
> maybe johndoe) and invoke another service on behalf of the same principle.
> or we can bind it statically, so the partnerLink will always invoke on
> behalf of johndoe.
So you want to share the principle across partnerLinks without
explicitly copying auth-data into the EPRs? Thats certainly not that
easy without extending BPEL.
Otherwise my proposal would be having a WS-A-extension like that:
<assign>
<copy>
<from>
<literal>
<sref:service-ref>
<addr:EndpointReference>
<addr:Address>http://example.com/auction/RegistrationService/</addr:Address>
<addr:ServiceName>as:RegistrationService</addr:ServiceName>
<basic-auth:user>admin</basic-auth:user>
<basic-auth:password>secret</basic-auth:password>
</addr:EndpointReference>
</sref:service-ref>
</literal>
</from>
<to partnerLink="auctionRegistrationService" />
</copy>
</assign>
Perhaps we're talking about the same thing with different words?
Best,
Tammo
