ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Boisvert" <boisv...@intalio.com>
Subject Re: Passing in Login and Password
Date Mon, 10 Sep 2007 00:48:39 GMT
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.

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