David E Jones wrote:
What I'm leaning towards above would be kind of like the auto-grant stuff if there was one permission for each artifact. The idea is to default to the level of full granularity (each artifact's name being the permission) and then make sure we have tools and conventions to make it easy (and even possible!) to deal with them.
In the design I'm working on, permissions can be granted to any artifact that has a security element. Artifacts that don't have a security element inherit permissions from artifacts higher up in the hierarchy that do have a security element. This eliminates having to name *everything* and instead you just name important security points.
The security element has an identifier attribute that is used to identify the artifact. I thought it would be simpler to just use the artifact's name, but not all artifacts have names. Then there is the case where an artifact might have a name, but it wouldn't make any sense to an administrator, or it could be better described for an administrator. (One example that Andrew pointed out is the EditExample screen. It is used for creating and editing Examples. So, from a security administration standpoint, CreateOrEditExample would be a better name.) Plus, it would be helpful to format artifact names in an authorization service friendly way.
In the case where a service calls other services, the called services inherit the permissions of the original service call.
-Adrian
