Willie Wheeler (Migrated from SEC-994) said:
for an explanation of what I’m proposing.
I saw Ben’s ADM-based suggestion in
but I think it’s fair to say that treating BRACE_LEFT (and probably even the connectives like CONDITION_AND) isn’t especially “natural”; the proposal clearly accommodates the way ConfigAttributeDefinition and ConfigAttributes currently works. What I’d propose is still kludgy, but at least it hides that kludginess from the app developer. The idea is that you could have an intercept-url like this:
(If the AND is too ugly there we could do something else.) The access attribute would enter LogicalBased as a single ConfigAttribute, and then LogicalBased would parse that into a logical expression. The logical atoms of that expression (such as ROLE_STUDENT) would be wrapped with a new ConfigAttribute and that in turn with a new ConfigAttributeDefinition, and then the CAD would be passed to the voters as usual. After the various voters are done evaluating the atoms, we could evaluate the logical expression with a three-valued logic (true, don’t care, false) and either grant or deny accordingly. (“Don’t care” corresponds to abstain.)
I’m attaching a proof of concept. It’s entirely hardcoded (i.e. no parser) but it shows that the concept works. I’m not sure whether this proposal unacceptably abuses ConfigAttributeDefinition and ConfigAttribute but I guess I’m putting it out there to get feedback. :-)
Luke Taylor said:
Thanks for the suggestion (and contribution). However, the planned support for EL-based access control should hopefully provide this kind of functionality out of the box, so I’m going to close this issue.