On 9/10/07, Alex Boisvert <[EMAIL PROTECTED]> wrote: > > On 9/10/07, Assaf Arkin <[EMAIL PROTECTED]> wrote: > > > > > 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 > > > Sorry, I misunderstood what you were asking. I was talking about > checking > security assertions on <bpel:receive>. > > For <bpel:invoke>, the extension would allow you to specify which > credentials (roles) you want to have propagated. The recipient is > responsible for checking your assertions.
I'm talking about invoke, not receive. Receive is a separate issue, which apparently I lost track of through this thread, so let's bring it back. Conceptually, a receive should use authorization to limit access based on user or role. (You only ever need one to grant access) I'm saying conceptually so we don't go mapping these two into attributes on receive. Practically the way you find the user/role to match against the receive requires a lot more capabilities. Can I have a list of users? Reference a group? Group with exclusion? Same combinations for roles? Can I not say anything but point to a service that will answer that question? Those all require a much more elaborate syntax. What does this do? > > > > sudo ssh myserver.com > > > > Per RBAC concept I'm executing on remote shell as sudo assaf, same > > activation. > > > > 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. > > > Actually, you can configure ssh (the client) to forward credentials for > you, > and you can use ssh-agent to create a security context that automatically > forwards credentials that you explicitly define (ssh-add). Same > principles, different implementation. Automatically forwards credentials (principal) or security context? The two are different. My point all along is that you're passing around principals -- credentials happen to be one way of doing it but not the only one -- so the invoke method only needs a way to map a principal into the invocation. This can be done in the invoke, the way you assign an output value or bring in a correlation, though should be it's own extensions for this specific purpose, or brought in from the EPR. Assaf alex >
