On 9/10/07, Alex Boisvert <[EMAIL PROTECTED]> 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. 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. 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. So the only thing you're passing around are credentials. 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? Assaf alex >
