qpid-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From c...@apache.org
Subject qpid-dispatch git commit: NOJIRA: add a TODO list for policy design/implementation
Date Sat, 02 Apr 2016 15:34:32 GMT
Repository: qpid-dispatch
Updated Branches:
  refs/heads/master 32e0a0298 -> 9b2d09fa0

NOJIRA: add a TODO list for policy design/implementation

Project: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/repo
Commit: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/commit/9b2d09fa
Tree: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/tree/9b2d09fa
Diff: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/diff/9b2d09fa

Branch: refs/heads/master
Commit: 9b2d09fa09f24c57458bfe60f87a35c45f47f685
Parents: 32e0a02
Author: Chug <chug@apache.org>
Authored: Sat Apr 2 11:34:05 2016 -0400
Committer: Chug <chug@apache.org>
Committed: Sat Apr 2 11:34:05 2016 -0400

 doc/notes/qdr-policy-todo.md | 55 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/doc/notes/qdr-policy-todo.md b/doc/notes/qdr-policy-todo.md
new file mode 100644
index 0000000..de35609
--- /dev/null
+++ b/doc/notes/qdr-policy-todo.md
@@ -0,0 +1,55 @@
+.. Licensed to the Apache Software Foundation (ASF) under one
+   or more contributor license agreements.  See the NOTICE file
+   distributed with this work for additional information
+   regarding copyright ownership.  The ASF licenses this file
+   to you under the Apache License, Version 2.0 (the
+   "License"); you may not use this file except in compliance
+   with the License.  You may obtain a copy of the License at
+     http://www.apache.org/licenses/LICENSE-2.0
+   Unless required by applicable law or agreed to in writing,
+   software distributed under the License is distributed on an
+   KIND, either express or implied.  See the License for the
+   specific language governing permissions and limitations
+   under the License.
+Policy TODO List
+# Ruleset schema
+- Should relesets be able to share definitions? The rulesets are self contained. Rulesets
uniquely define policy for one application. Redefinition of a ruleset will have no effect
on other applications. The implication is that if one ruleset has a large definition of users,
user groups, or policy settings then these definitions can not be shared with other rulesets
and *they must be repeated*.
+- Are the policy settings adequate? Do they provide enough controls over AMQP?
+    - The policy can allow or deny access to source/target **$management**. But once that
access is granted the user can do anything to any object on any router. Finer control over
management is desirable.
+    - Are user connection counts specified at the proper level? They are specified per application
but the counts are applied equally to users in all user groups.
+- Are white list rules (only allow rules) enough? Having only white list rules makes rulesets
(1) easier to comprehend and (2) easier to generate. The code to process them is also (3)
easier to write and (4) easier to test. Mixed allow and deny rules provide a richer rule specification
but with a cost impacting each of the benefit points.
+- Policy adds map schema objects. The schema processor verifies that the objects are maps
but does not look into the map to see if it makes any sense for policy. Policy code thoroughly
validates the maps but it would be better if the maps were specified in the management schema
and verified there.
+    - Schema map objects forced modifying the config processor to allow .json files in addition
to the existing .conf files.
+# Policy service
+- Current policy is local only. Certainly policy rulesets are manageable entities and may
be loaded through normal management channels. There is an opportunity to develop a policy
service where routers could open a channel to **$policy** for user lookup and policy settings.
Then each router would not need to maintain local policy in its current form.
+# Implementation
+- Effecting denials of application connections, sessions, and links are all handled in the
same way. Take an Open for instance. If an Open is denied then QDR returns an Open to the
client followed immediately with a Close that has a condition and a description. In all cases
the condition is amqp:resource-limit-exceeded. An improvement would be to use amqp:unauthorized-access
for denials that are hard policy denials and use resource-limit-exceeded for connections denied
by connection counts that may change later. 
+- Locking. Needs review.
+- Memory pool for policy settings. Uses alloc/free for each connection for small setting
structs. Low priority.
+- Add default 'default settings'. In the absence of policy settings, or in the presence of
policies without some settings, dispatch router needs to insert values into AMQP fields. The
current implementation hard codes these but they should all be configurable.
+# Usual suspects
+- Improve documentation.
+- Improve self tests.

To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org

View raw message