ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: Passing in Login and Password
Date Mon, 10 Sep 2007 03:32:53 GMT
On 9/9/07, Alex Boisvert <boisvert@intalio.com> 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 <tvanlessen@gmail.com> wrote:
> >
> > 2007/9/10, Assaf Arkin <arkin@intalio.com>:
> > > On 9/9/07, Tammo van Lessen <tvanlessen@gmail.com> wrote:
> > > >
> > > > 2007/9/7, Assaf Arkin <arkin@intalio.com>:
> > > > > 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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message