Authorization and Relational Indexes
Ian Boston
AuthZ in K2
http://sakai-kernel.googlegroups.com/web/Authorization.pdf
Relational Index Maintenance
http://sakai-kernel.googlegroups.com/web/RelationalIndexes.pdf
Ian
Clay Fenlason
On a first read one portion of the authz doc stands out particularly:
"We are only able to express Authorization hierarchy based on the
hierarchy of the content system as this defines the parent
relationship, however it is likely multiple potential single parent
hierarchies would create concepts too complex to express in any
reasonable UX."
It sounds like what you have in view in that latter point would be
parallel hierarchies of "content" and "people", some loosely-coupled
mechanism to map between them, and then some UX that allows these two
to work together in such a way that users can hope to follow who has
access to what. It might be a little discomfiting to have the K2 team
make assertions about what a reasonable UX could do, but I'm assuming
there are some long hours of CARET conversation and experimentation
lying behind the claim.
The underlying suggestion, painted in impressionistic strokes, seems
to be this: the shape of a content-hierarchy in a higher ed context
can be a fair approximation of the people-hierarchy engaged with it.
That sounds like it might be a shrewd insight. Or maybe it requires
adjusted notions of what content means. Or maybe it's very wrong. Or
maybe I'm just interpreting it wrong.
I feel the argument is probably right, but that it will require some
extra care in our content model, and we may need to come to terms with
constraints on our UX horizon. I'm not familiar enough with other
content models in practice to know where the issues might be. From
one direction the planned approach - of having the authorization
hierarchy proceed from the content hierarchy - has a certain elegance,
from another it sounds like a conflation that could prove a hindrance
(especially in the confused tangle of academic hierarchies). It may
well be a hindrance worth absorbing in a tradeoff, but I'd want to be
clearer about potential consequences, and make sure the UX workers are
alert to the boundaries.
~Clay
Clay Fenlason
Director, Educational Technology
Georgia Institute of Technology
(404) 385-6644
Ian Boston
1. Performance
2. Which one is authoritative.
We can probably fix 1, but not in the first iteration, but to fix 2...
who knows.. there are probably lots of solutions.
Binding to a the content hierarchy is really just a fast way of
resolving the parent, but we could probably use a node property to
point to some other content item as the AuthZ parent, so its not that
hard to implement.
With multiple parents, you might want to have a priority or weighting
on each parent... but what would that mean ? and how would it be
expressed in a UI/UX.
Over the years we have had many conversations about AuthZ and every
time they get really complicated and confusing, so the one thing I do
know is.... complexity in AuthZ is hard to express well in a UX/UI....
simple is good.
Ian
Clay Fenlason
implementations in the wild (of JCR-land) that might have something
to tell us about what this means practically for the user experience
of content management? Something that might suggest to us "this kind
of user interaction then becomes easier to achieve" and "this kind
becomes harder." Or are we paving new ground?
That is to say, I'm not doubting that it's better so much as that I'm
hoping that we can be clear-eyed about implications, and my lack of
practical experience in this area is getting in the way.
~Clay
Ian Boston
hierarchies exposed in the UI even if they have it underneath as this
tends to be hidden from the user for simplicity purposes.
The one place where you do see this sort of thing exposed to the user
is in Windows ACL's.... and in general they are quite confusing to the
average user....even though they are single parent,based on the filing
system.
I think we need to tread carefully, make the underlying system capable
and let the UX work take what is necessary and desirable. What I do
know is that we need to be able to express ACL's on objects in a way
that the management of those ACL's is scalable.
Ian
Ray Davis
requirement for group-specific role-to-permissions mapping, possibly for
reasons of backwards compatibility.
I believe that prioritizing this use case was a major flaw in K1's
approach to "realms": it doesn't match the vast majority of real-world
scenarios I've seen, and, given the number of permissions and the number
of groups we're dealing with, it's hard to picture how it could be
administered easily enough to *become* a common use case. What we more
typically find (if we abstract from Sakai's current design to the
functionality required for the most common use cases) is an
installation-wide mapping of roles to permissions. For more detail, see:
http://jira.sakaiproject.org/jira/browse/SAK-2660
Prioritizing this simpler and more common scenario might help with
scalability and UX constraints.
Best,
Ray
Lance Speelmon
concern. The triple than Ian refers to covers the who, the what, and
the where. What I am wondering if we should include "the when"?
Having access control statements that are only good for a certain
period of time would be most useful. Given the model, I do not think
dates would add any substantial amount of overhead in terms of
performance. Thoughts? L
Lance Speelmon +1 (317) 278-9053
Scholarly Technologist
Knoop, Peter
-peter
pa...@pbristow.id.au
The ACS could include a reference to a rule (effectively a foreign key
into a rule subsystem). Where this was not null resolution would
include a call to the rule subsystem to invoke the linked rule,
probably including the userEnvironment and object properties as
parameters which could be used in evaluating it. For simple time
related rules user and object attributes are probably unnecessary, but
they would allow for more sophisticated rules.
This could probably be added at a later date
Paul
Clay Fenlason
have to say http://confluence.sakaiproject.org/confluence/x/CIIe
and https://source.sakaiproject.org/contrib/conditionalrelease/
We've been running a rules-based approach for the last year, based on
this contrib work, so I'll put Carl on the spot to suggest where its
strengths and weaknesses lie.
~Clay
pa...@pbristow.id.au
Looking at the code (branch 2.4.x) it looks like the dynamic rule
adding (and switching/invoking?) is yet to be implemented? Should
AssignmentUpdate and AssignmentGrading implement a common interface so
ResourceReleaseRule doesn't need to be hard coded for them? Could
AssignmentUpdate etc be restful services whose signature could be
stored in a rule table and invoked by the Rule?
Agree completely that it's difficult to have a UI which protects users
from logical errors. I think UIs should typically have a subset of
rule functionality.
Paul
Ian Boston
damage usability. If roles are mapped institution wide, how does an
individual become a teacher in one context and a learner in another
within the same system ?
If I have missed the point, please say.
Ian
Ian Boston
only have 3 types of subject token... another one could be "group with
rule". I would not want to hard code rules into the core resolution
process and I would not want to have lots of subjecttoken types.
Another subject token type that I think is missing is 'owner'
Ian
Ian Boston
:)
Ian Boston
resolution you have to make it very fast if you don't want to make
those objects that have a ACS with a rule subject token make it all
crawl.
The advantage of this approach over K1 is that the rule code never
gets invoked, except where there is a rule subject token in an ACS,
selected by a permission query, so any slow down can be very precise.
eg: "only allow updates to this object between the hours of 4am and
9am" would only be evaluated when an update was attempted and not
impact read.
Ian
pa...@pbristow.id.au
An interface for rule implementation could allow for ttl to be
specified - if restful the http response could use the expires header?
In the example above the rule implementation could specify caching the
result for the triple until 4am if refused or 9am if granted. In other
cases a rule might specify no caching, or a fixed period eg 10
minutes, 24 hours depending on rule complexity and criticality of
access control.
I'd see this subsystem as a separate module (with condition cache)
inside the jvm with rule implementations potentially both inside the
jvm or called externally, probably through http. Low latency to the
condition subsystem and cache with higher latency to externally
implemented rules. But my fondness for the existing group provider
interface which I use and cache like this (except for the externally
specified TTL) may be unduly influencing me ;)
Paul
Ian Boston
So the subject token would bind to the service that is provided by a
separate component. We can probably make that binding generic and by
name to allow extension, although at present we don't register
services by name, just by class.
At some point in the security service it should be possible to allow
registration of subject token resolvers.
I am just re-writing the AuthN core, but once that is done I will
commit a change that opens the way up to creating this type of
component.
Ian
>
>
> Paul
> >
Michael Korcuska
* Each role has a default role-permission mapping. This doesn't mean a
user is stuck in a role. They may have a different role in each group
they belong to.
* Groups do NOT have their own role-permission mapping by default.
They use the system-wide one. This is, from the jira, *not* how Sakai
2.x works.
* Groups can override the default role-permission mapping. This is an
edge case. More often you will want to assign special permissions to
individuals rather than changing the groups role-permission mapping.
(I don't know if this is true, I'm just trying to clarify the point.)
* There will still be different types of groups (realms) that specify
different roles and roles and permissions.
Do I have this right, Ray?
I guess the efficiency gained is that we aren't carrying around a copy
of the role-permission mapping for every group in existence, only
those that are the "edge cases". I can't speak to what that actually
saves us, of course.
Michael
Michael Korcuska
Executive Director, Sakai Foundation
mkor...@sakaifoundation.org
phone: +1 510-931-6559
mobile (US): +1 510-599-2586
mobile (FR): +33 (0)6 31 11 58 97
skype: mkorcuska
Ian Boston
On 6 Jan 2009, at 06:54, Michael Korcuska wrote:
>
> I think the suggestion is as follows:
>
> * Each role has a default role-permission mapping. This doesn't mean a
> user is stuck in a role. They may have a different role in each group
> they belong to.
> * Groups do NOT have their own role-permission mapping by default.
> They use the system-wide one. This is, from the jira, *not* how Sakai
> 2.x works.
Michael Korcuska
I think this relates nicely to a discussion on the pedagogy list where
a teaching and learning use case describes an instance where an
instructor wants students to be able to access a file only once (in
this case to play an audio file). I assume this would be handled by a
rule that said "if access.count = 0" or some such. Am I imagining
this correctly?
Here's the relevant post from the pedagogy list (or check the list
itself for the full thread of interesting comments):
http://www.stanford.edu/people/kenro/essays/Sakai3ProposalComments.htm
Ian Boston
I think what is being asked for is either role or group inheritance.
What's not clear is the mechanism to deny an inherited grant.
Ian
On 6 Jan 2009, at 06:54, Michael Korcuska wrote:
Michael Korcuska
On Jan 6, 2009, at 08:56, Ian Boston wrote:
>
>
> On 6 Jan 2009, at 06:54, Michael Korcuska wrote:
>
>>
>> I think the suggestion is as follows:
>>
>> * Each role has a default role-permission mapping. This doesn't
>> mean a
>> user is stuck in a role. They may have a different role in each group
>> they belong to.
>> * Groups do NOT have their own role-permission mapping by default.
>> They use the system-wide one. This is, from the jira, *not* how Sakai
>> 2.x works.
>
>
> Hmmm, will have to rethink the AuthZ system.
but obviously take your word for it. Ray's jira was an efficiency
suggestion, I think, not a change in overall functionality (although
he will wake up in about 8 hours and undoubtedly correct me). And
therefore an implementation 'detail'.
In any case, this is my understanding of the functional behavior of
Sakai 2.x.
* Users can be members of groups (called sites in 2.x).
* There can be different types of groups that have different roles
associated with them. (Group types are called realms.)
* Each group type has a set roles associated with it.
* Each role has a set of permissions associated with it.
* A group gets its roles from its group type. And therefore the
permissions associated with those roles.
* Each group can have a set of permissions associated with its roles
that differs from the default role permissions from the group type.
That is, each group can have its own role-permission mapping.
* Each user is assigned a single role in each group he is a member of.
* Users can have a different role in each group they belong to.
* Users can have individual permissions that differ from the default
permissions associate with their role.
* I think, but am unsure, that a role can't exist in multiple realms.
I'm not sure why this would be the case. It seems just as easy to me
to have roles exist "independently" and the realm simply list which
roles are, by default, part of groups created in those realms. This
seems more flexible to me but I know others have much more knowledge,
experience, expertise and pain around these types of issues.
In any case, with the caveat of the last bullet, I think this makes
sense for Sakai 3 as well.
Now a potential diversion that will likely show my complete ignorance.
It occurs to me that AuthZ is particularly complicated in the world of
Sakai 3 where the site-content relationship is opened up. In Sakai 2
I could (generally /probably) assume that a user was getting at a bit
of content from within the context of a site and, therefore, their
permissions in that site were all that I cared about. So, simple enough.
But now we have a world with content sitting in a big bag somewhere
and there are a variety of groups that include (rather than "own")
that content. So if I'm an instructor in one group and a student in
another group but both groups point to the same bit of content then
what should Sakai do? I guess I have to check all the contexts
(groups) that both the content and user are associated with and
resolve the permissions thusly. Hierarchy is one of the real
complicating factors. This could get ugly, I think, but maybe it is
simpler or less common than I'm imagining.
In any case, I'll stop there.
Michael Korcuska
Hierarchy is, I think, one of the ugly factors. If I have maintain
rights in Group A and someone (me!) creates a SubGroup B, do I
automatically have maintain rights there? Or do I need to be added as
a member of that subgroups and be explicitly given those rights? For
an instructor managing multiple sections and or adhoc groups, it would
be a pain to have to manually add myself to each subgroup. I'd be
operating under the assumption: "I own group A. Therefore I own all
subgroups. Please do the right thing."
In other cases you'd want just the opposite. This is certainly role
specific. For certain roles permissions (and membership in subgroups)
are inherited. For other roles they aren't.
I'm feeling the need for a set of use cases to test the thinking
against....
Michael
pa...@pbristow.id.au
> I think this relates nicely to a discussion on the pedagogy list where
> a teaching and learning use case describes an instance where an
> instructor wants students to be able to access a file only once (in
> this case to play an audio file). I assume this would be handled by a
> rule that said "if access.count = 0" or some such. Am I imagining
> this correctly?
implementation would need access to the access.count for the user.
This implementation could be in the content hosting service or in the
tool where the file is linked from if the rule is really 'accessed
only once through this site'. A reference to the rule would be
'attached in some as yet undefined way' to the ACS. The condition
service would turn the reference into a call to the rule
implementation when the file was accessed.
(I'm not sure if this concept of access rules for a resource use is
problematic - does the ACS apply to the resource or to the use of it?
If a resource is used in more than one place can different ACSs be
applied to each use? )
The difficult bit is probably making the rule available through a user
interface so the instructor can safely and easily link it to the ACS
for the resource.
BTW the Stanford link 404s for me :(
Paul
Michael Korcuska
http://www.stanford.edu/people/kenro/essays/Sakai3ProposalComments.html
Ian Boston
SubjectStatement) Providers. Have a look at commit #56570.
If someone wants to they could implement a SubjectTokenProvider and
register it in the Registy named SubjectStatement.PROVIDER_REGISTRY
Ian
Ray Davis
installation wide, but user-to-role(s) is scoped by group context.
Membership = Agent + Group + Role
Role = Role ID + Permissions + metadata
A known but less common use case involves customizing permissions for
specific users in specific contexts. As I understand it, this is an
advantage of the Bodington approach, but to be useful that does require
software engineers to consider UX factors when defining permissions.
(For an example of what end users would be faced with otherwise, see the
permissions list in Sakai's Realms tool.) If it turns out to be
impossible to clean up our permissions act, and if its required for K2
to support that use case, it might make sense to allow for additive
roles which clump particular application-specific permissions (e.g., an
"Editor" role which provides control over public release of draft
content and which is unattached to institutional roles such as
"Instructor" or "Student").
But in my experience, the *least* common use case (and the hardest to
support over time) is the one in which role-to-permissions is customized
for a particular context.
Best,
Ray
Ray Davis
* Group-specific role-permission maps are such an edge case that it
might not even be worth supporting them in the out-of-the-box core system.
* This isn't just a matter of improved performance and data storage --
it's also a matter of user-visible functionality (the current Sakai
permissions system is too complex and counterintuitive to show
instructors) and support costs (currently we have to write special and
fairly complex SQL scripts for every Sakai upgrade).
Best,
Ray
Ray Davis
with a many-to-many relation of groups to contexts, but it's one that we
already face (and have already ignored): in Sakai 2.*, it's possible to
create a course site whose membership includes one class where Joe Phud
is an instructor and a second class where Joe Phud is a student. Add a
gradebook to the course site. Hilarity ensues.
Figuring out how to deal with such issues is why hereabouts we believe
that group-and-role management is worthy of its own full-scale project
and why we're putting resources into it. As I've said before, so far as
core services are concerned, this interesting aspect of authz is pretty
much the only difference between higher education and other areas I've
worked.
Best,
Ray
Michael Korcuska
here, Ray. While I do agree that Sakai's permission set is so complex
that it can't simply be exposed to end users, there are certain
particular cases that are likely to come up over and over again that
could be exposed to end users in a straightforward way. For example,
give this student permission to post announcements or create a forum
post or whatever.
As for the support costs, that's a good point that I don't understand
well enough. Not asking for an explanation, mind you.
Michael
John Norman
The point about complexity of permissions is not just in the interface
choices, it is also in the mental model you are asking the user to
carry around. So if they have one set of rights in one site, but a
different set in another site through some combination of installation-
wide role and site-role (or even individual permissions and/or special
content status) and things do not behave as they expect as a result,
that is a UX problem. And probably a helpdesk problem too.
John
Michael Korcuska
What I meant to say was: I'm not sure worrying about how these will be
exposed to the user is a reason for eliminating the capability of
group or user specific permissions from the system.
Although I am reminded of one of my favorite UX quotes:
"A good user interface doesn't hide the complexity of the system from
the user, it reveals the underlying simplicity of the system"
I don't have an attribution, although I heard it from Dan Halabe, a
fellow student at Northwestern some years ago (could it really be 15?).
All this said, the notion of a role having a different meaning in
different groups sounds just wrong to me. That I agree that the system
doesn't need to support that use case. The ability to override
specific permissions for an individual in a particular context seems
worthwhile, even if we don't know how to expose it elegantly in the UI.
John Norman
i.e. have we conceived of the optimum permission model in current
Sakai (we think not)? In rethinking permissions, should we continue to
aim for ultimate flexibility, or is there a simpler model that works
better? If there is a simpler model that works better, what should it
be? I think your last paragraph amounts to agreeing with Ray (if I
understood his point correctly), i.e. the idea of what person can do
as a professor or student is largely fixed from site to site. In
current Sakai it can be changed site by site. It is an interesting
question if it is easier for the subject of the permission changes to
understand that their site-wide role permission expectations are
different in a particular site because the admin changed it for them
as an individual or if they did it for all in the same role in the
site. Think of "I want all students in this site to be able to create
and edit wiki pages" when the site-wide default behaviour is Edit but
not Create. Is this better set at site-role level or on individual
permissions?
Like I said, this is a complicated area. It is also one of the areas
in which Sakai diverges from more conventional software - by
supporting much greater variation/flexibility so there are fewer
external models to help us think it through.
As I understand it, Ian is still aiming for something like 'ultimate
flexibility' so we will have choices about how we do things. That
doesn't mean all of that flexibility needs to be exposed to users and
so there are 2 levels at which the discussion could take place; what
should the system be capable of doing, and what should be the
functionality to which users are exposed?
John
Ian Boston
On 7 Jan 2009, at 13:14, John Norman wrote:
> As I understand it, Ian is still aiming for something like 'ultimate
> flexibility' so we will have choices about how we do things. That
> doesn't mean all of that flexibility needs to be exposed to users and
> so there are 2 levels at which the discussion could take place; what
> should the system be capable of doing, and what should be the
> functionality to which users are exposed?
Thats my intention, I am listening to this discussion, validating the
model as it stands and adjusting where necessary. So far I haven't
seen anything that worries me. (although I need to implement some
additions).
For me, as always, the issue is a UX that is simple to use and
powerful, whatever is done deep down in the kernel must not prevent
that.
Ian
Clay Fenlason
- is the site type. It is a "soft" measure that doesn't solve
matters, and introduces some of its own difficulties, but it can make
it easier to come to understand "this is a different kind of space,
with a different set of rules." As far as the UX goes, it's not
strictly an authz problem.
~Clay
Ray Davis
> I'm not sure I agree that the user-facing issues are a key factor
> here, Ray. While I do agree that Sakai's permission set is so complex
> that it can't simply be exposed to end users, there are certain
> particular cases that are likely to come up over and over again that
> could be exposed to end users in a straightforward way. For example,
> give this student permission to post announcements or create a forum
> post or whatever.
As you noted in a later message, this is a user-to-permission mapping,
and I'm only advocating the removal of (group-plus-role)-to-permission
mapping. No one has complained much about how difficult it is to take
advantage of Sakai 2.*'s ability to customize role-to-permission
mappings, and that's because no one wants it much -- the few cases I've
heard of would have been more directly addressed by user-to-permission
customization. End users and administrators expect installation-wide
roles to *mean* something, and in authz terms what a role means is
permissions.
> As for the support costs, that's a good point that I don't understand
> well enough. Not asking for an explanation, mind you.
Well, due to some comments further down the stream, you're gonna get one
anyway. :) These are pulled from SAK-2660.
1. Pretty much every time we add a new tool to Sakai, new permissions
are added to the system. They need to get associated with the standard
role-to-permission templates in our upgrade SQL scripts:
INSERT INTO SAKAI_REALM_FUNCTION VALUES
(SAKAI_REALM_FUNCTION_SEQ.NEXTVAL, 'osp.wizard.view');
...
INSERT INTO SAKAI_REALM_RL_FN VALUES((select REALM_KEY from SAKAI_REALM
where REALM_ID = '!site.template'), (select ROLE_KEY from
SAKAI_REALM_ROLE where ROLE_NAME = 'access'), (select FUNCTION_KEY from
SAKAI_REALM_FUNCTION where FUNCTION_NAME = 'osp.wizard.view'));
...
INSERT INTO SAKAI_REALM_RL_FN VALUES((select REALM_KEY from SAKAI_REALM
where REALM_ID = '!site.template.course'), (select ROLE_KEY from
SAKAI_REALM_ROLE where ROLE_NAME = 'Student'), (select FUNCTION_KEY from
SAKAI_REALM_FUNCTION where FUNCTION_NAME = 'osp.wizard.view'));
...
INSERT INTO SAKAI_REALM_RL_FN VALUES((select REALM_KEY from SAKAI_REALM
where REALM_ID = '!site.template.course'), (select ROLE_KEY from
SAKAI_REALM_ROLE where ROLE_NAME = 'Teaching Assistant'), (select
FUNCTION_KEY from SAKAI_REALM_FUNCTION where FUNCTION_NAME =
'osp.wizard.view'));
...
INSERT INTO SAKAI_REALM_RL_FN VALUES((select REALM_KEY from SAKAI_REALM
where REALM_ID = '!group.template'), (select ROLE_KEY from
SAKAI_REALM_ROLE where ROLE_NAME = 'access'), (select FUNCTION_KEY from
SAKAI_REALM_FUNCTION where FUNCTION_NAME = 'osp.wizard.view'));
...
INSERT INTO SAKAI_REALM_RL_FN VALUES((select REALM_KEY from SAKAI_REALM
where REALM_ID = '!group.template.course'), (select ROLE_KEY from
SAKAI_REALM_ROLE where ROLE_NAME = 'Student'), (select FUNCTION_KEY from
SAKAI_REALM_FUNCTION where FUNCTION_NAME = 'osp.wizard.view'));
... well, that's probably enough to give you an idea. However these are
*only* the templates (and therefore only apply to new sites), and *only*
the default out-of-the-box roles. As a result, as part of the upgrade,
support staff get stuck with the job of understanding the intent of
these none-too-transparent codes and writing our own SQL scripts or
utility programs to add the new records across our DB as seems applicable.
2. The institution or support staff decide that we need a new role with
a new set of permissions. As a real-life example, we might want to add a
"Head TA" role or a "Concurrent Student" role to an existing
installation. We can add the new role to the templates easily enough,
but it will not show up in any existing sites -- which means that
instructors and admins who want to add students will see different
things in the same site type depending on when the site was created.
3. A role's permissions needs to be changed due to a change in security
policy (for example, "SIS is going to pull the plug unless we
immediately block students from seeing other student's roster photos")
or to having misunderstood the meaning of a permission in the first
place. When this real-life problem comes up, it needs to be solved in a
hurry. But there is currently no support for it in Sakai. In fact,
customized role-to-permission mappings *conflict* with predictable
handling of this requirement: Are we supposed to touch those customized
mappings or leave them alone? What was the customizer's intent?
4. Tool or service developers may need to add new permissions to reflect
new capabilities. They may even decide to start treating an existing
permission in a completely different way. (<irony>Because after all,
it's just a detail of their internal implementation, right?</irony>)
This is a more expensive variant of scenario (1): we might be able to
delay adding new permissions for a whole new tool to existing sites that
don't yet have that tool, but we can't allow the software in existing
sites to start handling existing members incorrectly.
Best,
Ray
Ray Davis
On 1/7/2009 2:26 AM, Michael Korcuska wrote:
> I'm not sure I agree that the user-facing issues are a key factor
> here, Ray. While I do agree that Sakai's permission set is so complex
> that it can't simply be exposed to end users, there are certain
> particular cases that are likely to come up over and over again that
> could be exposed to end users in a straightforward way. For example,
> give this student permission to post announcements or create a forum
> post or whatever.
As you noted in a later message, this is a user-to-permission mapping,
and I'm only advocating the removal of (group-plus-role)-to-permission
mapping. No one has complained much about how difficult it is to take
advantage of Sakai 2.*'s ability to customize role-to-permission
mappings, and that's because no one wants it much -- the few cases I've
heard of would have been more directly addressed by user-to-permission
customization. End users and administrators expect installation-wide
roles to *mean* something, and in authz terms what a role means is
permissions.
> As for the support costs, that's a good point that I don't understand
> well enough. Not asking for an explanation, mind you.
Well, due to some comments further down the stream, you're gonna get one
instructors and admins who want to add site members will see different
things in the same site type depending on when the site was created.
3. A role's permissions needs to be changed due to a change in security
policy (for example, "SIS is going to pull the plug unless we
immediately block students from seeing other students' roster photos")
or to having misunderstood the meaning of a permission in the first
place. When this real-life problem comes up, it needs to be solved in a
hurry. But there is currently no support for it in Sakai. In fact,
customized role-to-permission mappings *conflict* with predictable
handling of this requirement: Are we supposed to touch those customized
mappings or leave them alone? What was the customizer's intent?
4. Tool or service developers may need to add new permissions to reflect
new capabilities. They may even decide to start treating an existing
permission in a completely different way. (<irony>Because after all,
it's just a detail of their internal implementation, right?</irony>)
This is a more expensive variant of scenario (1): we might be able to
delay adding new permissions for a whole new tool to existing sites that
don't yet have that tool, but we can't allow the software in existing
sites to start handling existing members incorrectly.
Best,
Ray
> On Jan 6, 2009, at 18:21, Ray Davis wrote:
Ian Boston
1. We use group-plus-role-to-permission all the time. We have 31
organizations at cambridge, and they have slightly different views of
what a role is and what it can do, and in research worksites, they
sometimes say they want specific things. IMVHO, its one of the key
differentiators that makes Sakai usable for research groups.
2. If you read the AuthZ document carefully, you will notice that the
mechanism for updating permissions does not involve SQL statements
like you have quoted, but thank you for sharing with us.
But you are right, the UI in 2 for managing this is unusable. Its
*not* going to be unusable in 3! (or we wont release 3 :))
Ian
Knoop, Peter
> From: sakai-...@googlegroups.com [mailto:sakai-
> ker...@googlegroups.com] On Behalf Of Ian Boston
> Sent: Wednesday, January 07, 2009 2:12 PM
> To: sakai-...@googlegroups.com
> Subject: [sakai-kernel] Re: Authorization and Relational Indexes
>
>
> 2 points,
>
> 1. We use group-plus-role-to-permission all the time. We have 31
> organizations at cambridge, and they have slightly different views of
> what a role is and what it can do, and in research worksites, they
> sometimes say they want specific things. IMVHO, its one of the key
> differentiators that makes Sakai usable for research groups.
For instance, in large lecture courses the out-of-the-box roles and permissions are often fine the way they are, where only the Instructor role can send emails to the class. In a small seminar course, however, the teacher sometimes wants the students to be able to send email or post announcements to the whole class list too. This can currently be accomplished by assigning the "new" permission the Student role.
(That of course means you've now got the same role with different permissions in different sites. I'll note that students don't necessarily see their role as "Student" in the UI in the current system. They're experience with what they can do in a site is more likely based on what they've been able to do in sites before, than an expectation set by "seeing" they have a certain role in a site. It's generally only instructors and the like that are directly confronted with the notion of roles in the current interface.)
In the future, I like the sound of having Roles mean specific things, such that their permissions are the same across the system (and change across the system when upgrade or an admin change demands it.) If someone needs to make a customization, like to Email Archive, how about adopting the behavior some systems have of simply forcing creation of a new role when a permission change is made to an existing role. For instance, as soon as you click to change a role's permissions, then a new "Custom" role would be created. Its permissions would be permissions based on the role you wanted to change, plus whatever change you made (or some approach like that...) You could also rename the new, custom role. You would also ask the user if they wished to re-assign everyone in the site with the current system-defined role they started with to the new custom role they've created; or, perhaps you would just do that for them automatically.
-peter
Ray Davis
11000 ourselves) might not consider 31+ customizations "all the time."
I've updated the JIRA ticket to include Cambridge's use case.
Thanks,
Ray
Michael Korcuska
initially making it seem like we weren't.
So the requirements, if I have it right, are something like:
* When new permissions are created or the permissions for a role are
modified, those permissions should be automatically available to
existing roles relevant to them.
* When new roles are added to a group type, existing groups of that
type should have those roles available automatically (or should the
admin have a choice?).
Centralization and Inheritance of roles/permissions (rather than
templates & copies) is probably the easiest way to implement this. But
one could imagine other solutions and I try to (have to) stay out of
the implementation business.
Michael
Ray Davis
> Thanks Ray, very helpful. And we're basically in agreement...sorry for
> initially making it seem like we weren't.
>
> So the requirements, if I have it right, are something like:
>
> * When new permissions are created or the permissions for a role are
> modified, those permissions should be automatically available to
> existing roles relevant to them.
> * When new roles are added to a group type, existing groups of that
> type should have those roles available automatically (or should the
> admin have a choice?).
>
> Centralization and Inheritance of roles/permissions (rather than
> templates & copies) is probably the easiest way to implement this. But
> one could imagine other solutions and I try to (have to) stay out of
> the implementation business.
If I can try to summarize the high-level requirements: Because the lists
of roles and permissions aren't static (and because the list of all
permissions is very long), it's important that the number of independent
role-to-permission mappings in the system not grow exponentially.
Otherwise it becomes too difficult to manage installation-wide changes
to roles and permissions.
We've established that one institution-wide set of mappings (which is
what I suggested as a starting goal) is too few. Cambridge will want
some organization-scoped sets of mappings and some research-group-scoped
sets of mappings; quite a few universities will probably want "site
types" (like Sakai's current course sites, project sites, and portfolio
sites) that use different sets of roles or interpret institution-wide
roles somewhat differently.
On the other hand, we've also established (in production) that an
independent set of role-to-permission mappings for every single site is
too many. (Which means that an independent set for every single *group*
-- every discussion section, every study group, etc. -- would be *way*
too many.)
So yes, speaking as another guy who's supposed to be staying out of this
implementation :) , I agree it sounds a lot like an "inheritance with
explicit override as needed but with the assumption that override points
are rare" model.
Best,
Ray