On 9/9/07, Tammo van Lessen <[EMAIL PROTECTED]> wrote: > > > 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.
Exactly, which is why we might want to consider 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> Imagine a process for which you'd be dealing with several different principles on the same service. If you have more than a couple of invocations you'll need a lot of assignments. Add a flow and you'll start having concurrency issues. Nothing that can't be solved (with more than one partnerLink for example) but that's a lot of work and unnecessary complexity in your process. So I also believe that adding some sort of authentication context is a better way. As for the wire format, WS-Security UsernameToken seems to be something we can reuse Cheers, Matthieu. Perhaps we're talking about the same thing with different words? > > Best, > Tammo >
