On 9/9/07, Assaf Arkin <[EMAIL PROTECTED]> wrote: > > > 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.
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. 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. No it doesn't. How did you come up with that conclusion? RBAC with role activation can work in a distributed environment with, e.g., a web of trust without central root to the system. alex
