On 9/9/07, Alex Boisvert <[EMAIL PROTECTED]> wrote: > > At a more abstract level, I was thinking about BPEL extensions whereby you > could assert identity (e.g. subject/principal/user) and authority (e.g. > roles), such as > > <bpel:invoke> > <rbac-ext:assert user="..." roles="..." /> <!-- propagate > identity > and/or authority assertions --> > </bpel:invoke> > > (where propagation can happen through different protocols and types of > credentials) > > and > > <bpel:receive> > <rbac-ext:assert users="..." roles="..." /> > </bpel:receive> > > (to restrict operations to certain identities / authority groups) > > There's overlap here with some of the BPEL4People concepts (that borrow > and > extend the RBAC specs) so we might as well leverage the same semantic > wherever possible. Credentials would be stored/accessed from the security > context but would typically never be used directly in the process to > maximize portability.
I think it should be principal or role on receive, principal on invoke. Asserting that a user belongs to a role on receive is something that authorization system should deal with, no need to change the process definition each time an employee joins/leaves the company or changes jobs. Asserting that a user belongs to a role on invoke is pointless, the receiver should never trust your assertion and should make up their own determination upon receiving the message. Assaf alex > > > On 9/9/07, Tammo van Lessen <[EMAIL PROTECTED]> wrote: > > > > 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 > > >
