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 17:20:31 GMT
On 9/10/07, Alex Boisvert <boisvert@intalio.com> wrote:
> On 9/10/07, Assaf Arkin <arkin@intalio.com> wrote:
> >
> > On 9/10/07, Alex Boisvert <boisvert@intalio.com> wrote:
> > > That's not the point.  You may still want to have only JohnDoe or any
> HR
> > > personnel invoke a specific operation, irrespective of whether the
> > > operation
> > > is a workflow task.
> >
> > .. or fail the activity?  I'm totally missing how the activity expects
> to
> > behave.
> Similar to correlation on a receive, assertions effectively guard the
> activity from executing until all the necessary conditions have been met.

So basically:
1.  Receive with some principal, store in foo.
2.  Don't check.
3.  Invoke using foo, making assertion.
    3.1.  Get response, or
    3.2.  Crash

Correlations on invoke are a necessary evil because it so turns out that the
killer feature, using the correlation to stuff values in the outgoing
message, is hard to implement.  And the assignments are already problematic
enough that the least they could do is offer some checks and balances.

But checking roles on invoke?  I would think that if the principal shouldn't
do something, you would check for it and either not start the process, or
not go down that path, rather than react to a fault.

Loosely coupled is different from distributed.  In a loosely coupled
> > architecture you
> > a) never trust the client inputs but validate them yourself, and b)
> never
> > provide more information than you want a service to act upon
> Completely agree.
> That part we know works very well: HTTP basic/digest, WSSE security token,
> > SAML, JDBC, FTP, SSH, POP3, etc.  How do we send roles with assertions
> > around?  Can I send root (but treat as user) to a service that might
> then
> > end up being a JDBC call or SSH invocation?
> Speaking of Unix, "sudo" is a great example of role
> activation.  Assertions
> don't require trust in the sender/invoker; they only require trust in the
> signer.   Roles are a form of credential so it's legitimate to pass them
> around.

What does this do?

sudo ssh myserver.com

Per RBAC concept I'm executing on remote shell as sudo assaf, same

Per my SSH stack, I'm executing on remote shell as uncontrolled root.
Actually none of my servers allow me to sudo ssh into them.



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