Brian Stansberry [
https://community.jboss.org/people/brian.stansberry] commented on the
document
"Access control notes"
To view all comments on this document, visit:
https://community.jboss.org/docs/DOC-48596#comment-11917
--------------------------------------------------
Second try at this after the wiki turned my first one into a repost of the main
article...
Sorry, Heiko, this page was really notes to myself and wasn't really in a state for
publication. But word of it got out into the wild and it needed to be made visible.
I'll try and clean it up today.
The initial timing part was very much notes to myself. I do believe that's reasonable
for a design phase though.
About "Request Attributes"...
The basic idea I had in mind is that authorization decisions would be made by some sort of
authorization engine. The AS would define an SPI for this engine with an available set of
inputs that would be provided to the engine and an expected set of outputs -- permit,
deny, perhaps other stuff like the XACML "obligations" notion.
The inputs would be from 4 broad categories
1) Information about the operation.
2) Information about the resource being accessed
3) Information about the caller
4) General environmental stuff, e.g. time of day, interface the call came in on, etc.
+(This last is conceptual only and not something I propose dealing with in AS 8)+
The "Request Attributes" bits above are notes to myself to identify what stuff
from categories 1) and 2) above we would need to provide to a rules engine to provide
sufficient input for a set of rules that map to the various "roles" concepts
that we've seen in different permission schemes we've heard about. It's
basically thought on how to pursue the "Rules based approach" in the wiki
article Anil linked.
The idea I had at its core is the authorization system could be as flexibile as the rule
grammar and the available inputs will allow. Directly configuring the set of rules allows
the user the maximum flexibility. This is not something I see as being in scope for AS 8
though.
For AS 8 (and forever really) we need a simplified system with a limited number of config
options that internally generates (or statically defines) a set of rules that results in
behavior like one of the schemes I listed. So, if user is in role "Operator",
the rules would verify whether the operation is read-only, whether the resource or
attribute description has a security restriction associated etc.
Basically, the simplified system is a shorthand way of expressing a fairly complex set of
rules in a user-friendly fashion.
For the future, we can see if there are other, more flexibile shorthands for creating
rules (e.g. a regex scheme.) Or, if appropriate we can provide direct configurability of
the rules engine.
--------------------------------------------------