On May 6, 2009, at 11:07 AM, Adrian Crum wrote:
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.
What if a user finds their own "important security points" that we
have not already setup? Actually, I would argue that over time with
enough use nearly every screen, form, form field, service, and perhaps
other things would be designated as security points.
Why not just default to having anything and everything being a
potential security point and use tools and conventions to make it
easier to handle... but still totally flexible to configure externally
(ie without changing the code or configuration files, and without
restarting the system).
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.
Is it really worth all the effort to do so? Consider that one of the
nice things about using the actual/natural names and locations is that
for the most part we have been consistent in naming things so that
from the request name (in a URL) you can easily lookup screens and
forms and things, although the worst case scenario is that they have
to find the actual request in the ArtifactInfo stuff and then trace
down to the artifact they are looking for.
In general I am very against assigning additional and artificial names
to things... it just creates a level of confusion because people see
things referred to by different names and it's hard for experienced
people to keep track of which is which and what it's for... for more
casual users I suspect it would be a constant problem.
Also, which artifacts don't have any sort of name or identifier
(sorry, I can't think of any right now...)?
About EditExample, it could be "CreateOrUpdateExample" but the point
of using the word "Edit" was to avoid using the term "Create" or
"Update" and not imply that it was exclusive to one or the other.
In the case where a service calls other services, the called
services inherit the permissions of the original service call.
Yes, we can certainly have rules like this that help us deal with the
large number of artifacts.
-David
