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 Sun, 09 Sep 2007 22:07:32 GMT
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,

admin and johndoe are not roles either, but principles.  an authorization
system may grant access based on role, in which case admin may be both
principle and role; johndoe will likely be a principle associated with some
generic role (like 'user') or even several roles.

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.

Assaf


Cheers,
>   Tammo
>
> --
> Tammo van Lessen - tvanlessen@gmail.com - http://www.taval.de
>

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