On 9/9/07, Alex Boisvert <[EMAIL PROTECTED]> wrote: > > On 9/9/07, Assaf Arkin <[EMAIL PROTECTED]> wrote: > > > > 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. > > > A use-case for principal and role is when I want JohnDoe to approve his > report's leave of absence, or somebody with HR management role.
Isn't that an issue for a workflow task manager? A workflow task manager would allow you to specify who can take ownership of (perform) the task through various means, so you can certainly say johndoe and/or HR. Also who can observe the task, admin it, and so forth. But those are separate, and an task manager would still require you to authenticate as the creator of the task. Authorization should be about the invoker, nor the performer. 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. > > > An important RBAC concept is that of role activation. If you happen to > have > administrator role, you may not want to assert this authority at all times > because you might unknowingly use a privilege that you don't intent to > use, > or you don't want to delegate all your authority to a process that does > who-knows-what. Explicitly asserting roles allows you to control how > much > authority you're passing on. Except that concept brings with it the weight of a tightly-coupled centralized architecture for which it was designed, and I'm not sure it's a good idea to do that. Assaf alex >
