[CONF] Apache Qpid > ACL

[confluence]

ACL Page edited by Chuck Rolke Comment: Updated for general readability and to reflect significant changes to 0.16 C++ broker ACL handling. Changes (48) h2. v2 ACL file format for brokers This new The v2 ACL implementation file format has been designed for implementation and interoperability on all Qpid brokers. It is currently supported in the following brokers: || Broker || Version || ... | Java | M5 onward | This document is updated for release 0.16. *Contents* ... h3. Specification &nbsp;Notes on file formats h4. Comments * A line starting with the character '#' will be considered a comment, and are ignored. * Since the '#' char (and others that are commonly used for comments) are commonly found in routing keys and other AMQP literals, it is simpler (for now) to hold off on allowing trailing comments (ie comments in which everything following a '#' is considered a comment). This could be reviewed later once the rest of the format is finalized. * A line starting with the '#' character is considered a comment and is ignored. * Embedded comments and trailing comments are not allowed. ** The '#' character is commonly found in routing keys and other AMQP literals and occur naturally in ACL rule specifications. ** By disallowing embedded and trailing comments there is less confusion in writing ACL rules that work correctly. h4. White Space * Empty Blank lines ("") and lines that contain only whitespace (any combination of ' ', '\f', '\n', '\r', '\t', '\v') are ignored. * Additional whitespace between and after tokens is ignored. * Group and acl definition lines must start with "group" or "acl" respectively and with no preceding whitespace. h4. Character Set * ACL files use are constrained to 7-bit ASCII characters. * Group names may contain only ** *a-z* ** *A-Z* ** *0-9* ** *'-'* hyphen ** *'_'* underscore * Individual user names may contain only ** *a-z* ** *A-Z* ** *0-9* ** *'-'* hyphen ** *'_'* underscore ** *'.'* period ** *'@'* ampersand ** *'/'* slash h4. Case Sensitivity * All tokens are case sensitive. "name1" != "Name1" and "create" != "CREATE". * Group lists may be extended to the following line by terminating the line with the '\' character. However, this may only occur after the group name or any of the names following the group name. Empty extension lines (ie just a '\' character) are not permitted. * "name1" is not equal to "Name1" * "create" is not equal to "CREATE". h4. Line Continuation * Group name lists may be extended to the following line by terminating the current line with the '\' character. No other ACL file lines may be continued. * Group specification lines may be continued only after the group name or any of the names following the group name. See the example below. * Lines consisting solely of a '\' continuation character are not permitted. * The '\' continuation character is recognized only if it is the last character in the line. Any characters after the '\' are not permitted. {code} # Examples of extending group lists using a trailing '\' character ... name10 {code} * Additional whitespace (ie more than one whitespace char) between and after tokens is ignored. However group and acl definitions must start with "group" or "acl" respectively and with no preceding whitespace. * All acl rules are limited to a single line. * Rules are interpreted from the top of the file down until the name match is obtained; at which point processing stops. * The keyword "all" is reserved, and matches all individuals, groups and actions. It may be used in place of a group or individual name and/or an action - eg "acl allow all all", "acl deny all all" or "acl deny user1 all". * The last line of the file (whether present or not) will be assumed to be "acl deny all all". If present in the file, any lines below this one are ignored. * Property names, Usernames and group names may contain only *a-z , A-Z , 0-9 , '-' , '_' &amp; '.'*. * Rules must be preceded by any group definitions they may use; any name not previously defined as a group will be assumed to be that of an individual. * ACL rules must have the following tokens in order on a single line: ** The string literal "acl"; ** The permission; ** The name of a single group or individual or the keyword "all"; ** The name of an action or the keyword "all"; ** Optionally, a single object name or the keyword "all"; ** If the object is present, then optionally one or more property name-value pair(s) (in the form property=value). h4. Line Length * ACL file lines are limited to 1024 characters. h4. The *all* keyword * The keyword "all" is reserved and may be used in ACL rules to match all individuals and groups, all actions, or all objects. ** acl allow all all ** acl deny all all ** acl deny user1 all ** acl allow fred@QPID create all h4. ACL File Syntax {code} user = username[/domain[@realm]] ... group <group-name> = [user-list] [group-name-list] permission = [allow|allow-log|deny|deny-log] action = "" object = [virtualhost|queue|exchange|broker|link|route|method] property = [name|durable|owner|routingkey|passive|autodelete|exclusive|type|alternate|queuename|schemapackage|schemaclass] policytype|schemapackage|schemaclass| queuemaxsizelowerlimit|queuemaxsizeupperlimit| queuemaxcountlowerlimit|queuemaxcountupperlimit] acl permission {<group-name>|<user-name>|"all"} {action|"all"} [object|"all"] [property=<property-value>]] {code} h3. Validation * ACL rules must have the following tokens in order on a single line: ** The string literal "acl" ** The permission ** The name of a single group or of an individual, or the keyword "all" ** The name of an action, or the keyword "all" ** Optionally, a single object name, or the keyword "all" *** If the object is present, then optionally one or more property name-value pairs in the form 'property=value'. The new ACL file format needs to perform validation on the acl rules. The validation should be performed depending on the set value: h4. File Processing Overview strict-acl-validation=[none|warn*|error|fatal] The default setting should be 'warn' * ACL files are processed line by line from the top of the file down. * Group membership must be established before the group name is used in an ACL rule. On validation of this acl the following checks would be expected: h5. Deny Mode vs. Allow Mode * By default ACL files are in 'Deny Mode' and deny all actions by all users. That is, there is an implicit "acl deny all all" rule appended to the ACL rule list. In 'Deny Mode' any action by any actor is denied unless some other rule in the ACL file explicitly allows it. * Administrators may change an ACL file to 'Allow Mode' by ending the ACL file with "acl allow all all". When this rule is present at then end of the ACL file then any action by any actor is allowed unless some other rule in the ACL file explictly denys it. * C++ Brokers prior to release 0.16 had an optimization based on the Allow Mode or Deny Mode. ** In a Deny Mode ACL file all 'deny' or 'deny-log' rules are discarded. ** Similarly in an Allow Mode ACL file all 'allow' or 'allow-log' rules are discarded. ** This characteristic made specification of certain ACL rules difficult and confusing. * C++ Brokers after release 0.16 do not optimize the rules based on Allow Mode or Deny Mode. ** All rules are kept and processed in the order specified my the ACL file. ** Allow rules may be mixed with Deny rules and if a rule is matched then an allow or deny decision is rendered. {code} acl allow client publish routingkey=exampleQueue exchange=amq.direct # Example of C++ Broker Allow Mode processing behavior group admins bob@QPID joe@QPID acl allow bob@QPID create queue acl deny admins create queue acl allow all all # Prior to release 0.16 bob is denied permission to create a queue because the # 'allow bob@QPID create queue' rule in an Allow Mode file is discarded. # Since release 0.16 bob is allowed permission to create a queue because no # rules in the file are discarded and the first allow rule controls the decision. {code} # The If the user 'client' cannot be found, if the authentication mechanism cannot be queried then a 'user' value should be added to the file. # There is an exchange called 'amq.direct' # There is a queue bound to 'exampleQueue' on 'amq.direct' Each of these checks that fail will result in a log statement being generated. h4. Rule Processing Details In the case of a fatal logging the full file will be validated before the broker shuts down. * Rules are interpreted from the top of the file down until a matching rule is obtained. The matching rule then controls the allow or deny decision. h4. Rule Matching Details * The minimum matching criteria for all ACL rules are: ** An actor (individually named or group member) ** An action ** An object * If a rule does not match the minimum criteria then that rule does not control the ACL decision. * ACL rules optionally specify object names and property values: ** If an object is named and/or property values are specified in an ACL rule then all of them must match to cause the rule to match. {code} # Example of rule matching # # Using this ACL file content: (1) acl deny bob create exchange name=test durable=true passive=true (2) acl deny bob create exchange name=myEx type=direct (3) acl allow all all # # Lookup 1. id:bob action:create objectType:exchange name=test {durable=false passive=false type=direct alternate=} # # ACL Match Processing: # 1. Rule 1 passes minimum criteria with user bob, action create, and object exchange. # 2. Rule 1 matches name=test. # 3. Rule 1 does not match the rule's durable=false with the requested lookup of durable=true. # 4. Rule 1 does not control the decision and processing continues to Rule 2. # 5. Rule 2 passes minimum criteria with user bob, action create, and object exchange. # 6. Rule 2 does not match the rule's name=myEx with the requested lookup of name=test. # 7. Rule 2 does not control the decision and processing continues to Rule 3. # 8. Rule 3 matches everything and the decision is 'allow'. # # Lookup 2. id:bob action:create objectType:exchange name=myEx {durable=true passive=true type=direct alternate=} # # ACL Match Processing: # 1. Rule 1 passes minimum criteria with user bob, action create, and object exchange. # 6. Rule 1 does not match the rule's name=test with the requested lookup of name=myEx. # 4. Rule 1 does not control the decision and processing continues to Rule 2. # 5. Rule 2 passes minimum criteria with user bob, action create, and object exchange. # 2. Rule 2 matches name=myEx. # 3. Rule 2 matches the rule's type=direct with the requested lookup of type=direct. # 8. Rule 2 matches everything and the decision is 'deny'. # {code} * C++ Broker release 0.16 introduces new rule matching criteria. ** Certain rule properties are introduced that constrain settings from exceeding ACL minimums or maximums. ** When specified in an ACL allow rule these properties do not affect that rule's match determination. Rather, when the constraint is exceeded then the allow rule which is otherwise matched is converted into a deny rule. ** The new rule properties have no effect in deny rules. ** The new rule properties are: *** queuemaxsizelowerlimit *** queuemaxsizeupperlimit (alias: maxqueuesize) *** queuemaxcountlowerlimit *** queuemaxcountupperlimit (alias: maxqueuecount) {code} # Example of ACL specifying queue size constraints # Note: for legibility this acl line has been split into multiple lines. acl allow bob@QPID create queue name=q6 queuemaxsizelowerlimit=50 queuemaxsizeupperlimit=100 queuemaxcountlowerlimit=200 queuemaxcountupperlimit=300 # # These limits come into play when a queue is created as illustrated here: queue_options = {} queue_options["qpid.max_count"] = 101 queue_options["qpid.max_size"] = 100 session.queue_declare(queue="q6", arguments=queue_options) # # When the ACL rule is processed the actor, action, object, and object name all match # and so this allow rule matches for the allow or deny decision. However, the ACL rule # is further constrained to limit 50 <= max_size <= 100 and 200 <= max_count <= 300. # Since the queue_option max_count is 101 then the size limit is violated and the # allow rule is returned with a deny decision. {code} h3. Validation Note: In the 0.16 C++ Broker only the following validation is performed on ACL rule files: * Files are correctly formatted with respect to character sets, white space, continuation, and line length. * Permissions, Actions and Objects are correctly named. * Sufficient tokens are presented for each ACL rule. * Any validation error is fatal and the broker is shut down. * Every line in an ACL file is validated before the broker is shut down due to a validation failure. h3. Example file: ... h3. Mapping of ACL traps to action and type * The C++ broker maps the ACL traps in the follow way for AMQP 0-10:. * The Java broker currently only performs ACLs on the AMQP connection not on management functions:. * This table also shows which property values are allowed to be specified for each Object-Action pair. || Object|| Action|| Properties|| Trap C++|| Trap Java || ... |Exchange|Publish| name routingKey |SemanticState::route | BasicPublishMethodHandler | |Queue |Access | name |QueueHandlerImpl::query | - | |Queue |Create | name alternate passive durable exclusive autodelete policytype queuemaxsizelowerlimit queuemaxsizeupperlimit queuemaxcountlowerlimit queuemaxcountupperlimit |QueueHandlerImpl::declare | QueueDeclareHandler | |Queue |Purge | name |QueueHandlerImpl::purge | QueuePurgeHandler | |Queue |Purge | name |Management::Queue::purge | - | ... The file gets read top down and rule get passed based on the first match. In the following example the first rule is a dead rule. I.e. the second rule is wider than the first rule. DON'T do this, it will force extra analysis, worst case if the parser does not kill the dead rule you might get a false deny. The file gets read top down and rule get passed based on the first match. In the following example the first rule is unnecessary. The second rule is wider than the first rule and the same result would be achieved if the first rule was removed. {code} allow peter@QPID create queue name=tmp <-- dead rule!! acl allow peter@QPID create queue name=tmp <-- unnecessary rule causes extra work. acl allow peter@QPID create queue acl deny all all {code} ... {code} acl deny all all {code} ... {code} acl allow all all {code} Note that 'allow' based file will be a LOT faster for message transfer. This is because the AMQP specification does not allow for creating subscribes on publish, so the ACL is executed on every message transfer. Also, ACL's rules using less fewer properties on publish will in general be faster. h3. Getting ACL to Log ... {code} acl allow-log john@QPID all all acl deny-log guest@QPID all all {code} ... ACL Options: --acl-file FILE The policy file to load from, loaded from data dir {code} Full Content v2 ACL file format for brokers The v2 ACL file format has been designed for implementation and interoperability on all Qpid brokers. It is currently supported in the following brokers: Broker Version C++ M4 onward Java M5 onward This document is updated for release 0.16. Contents v2 ACL file format for brokers Specification Comments White Space Character Set Case Sensitivity Line Continuation Line Length The all keyword ACL File Syntax File Processing Overview Deny Mode vs. Allow Mode Rule Processing Details Rule Matching Details Validation Example file: Design Documentation Mapping of ACL traps to action and type v2 ACL User Guide Writing Good/Fast ACL Getting ACL to Log User Id / domains running with C++ broker Specification Comments A line starting with the '#' character is considered a comment and is ignored. Embedded comments and trailing comments are not allowed. The '#' character is commonly found in routing keys and other AMQP literals and occur naturally in ACL rule specifications. By disallowing embedded and trailing comments there is less confusion in writing ACL rules that work correctly. White Space Blank lines and lines that contain only whitespace (any combination of ' ', '\f', '\n', '\r', '\t', '\v') are ignored. Additional whitespace between and after tokens is ignored. Group and acl definition lines must start with "group" or "acl" respectively and with no preceding whitespace. Character Set ACL files use are constrained to 7-bit ASCII characters. Group names may contain only a-z A-Z 0-9 '-' hyphen '_' underscore Individual user names may contain only a-z A-Z 0-9 '-' hyphen '_' underscore '.' period '@' ampersand '/' slash Case Sensitivity All tokens are case sensitive. "name1" is not equal to "Name1" "create" is not equal to "CREATE". Line Continuation Group name lists may be extended to the following line by terminating the current line with the '\' character. No other ACL file lines may be continued. Group specification lines may be continued only after the group name or any of the names following the group name. See the example below. Lines consisting solely of a '\' continuation character are not permitted. The '\' continuation character is recognized only if it is the last character in the line. Any characters after the '\' are not permitted. # Examples of extending group lists using a trailing '\' character group group1 name1 name2 \ name3 name4 \ name5 group group2 \ group1 \ name6 # The following are illegal: # '\' must be after group name group \ group3 name7 name8 # No empty extension lines group group4 name9 \ \ name10 Line Length ACL file lines are limited to 1024 characters. The all keyword The keyword "all" is reserved and may be used in ACL rules to match all individuals and groups, all actions, or all objects. acl allow all all acl deny all all acl deny user1 all acl allow fred@QPID create all ACL File Syntax user = username[/domain[@realm]] user-list = user1 user2 user3 ... group-name-list = group1 group2 group3 ... group <group-name> = [user-list] [group-name-list] permission = [allow|allow-log|deny|deny-log] action = "" object = [virtualhost|queue|exchange|broker|link|route|method] property = [name|durable|owner|routingkey|passive|autodelete|exclusive|type|alternate|queuename| policytype|schemapackage|schemaclass| queuemaxsizelowerlimit|queuemaxsizeupperlimit| queuemaxcountlowerlimit|queuemaxcountupperlimit] acl permission {<group-name>|<user-name>|"all"} {action|"all"} [object|"all" [property=<property-value>]] ACL rules must have the following tokens in order on a single line: The string literal "acl" The permission The name of a single group or of an individual, or the keyword "all" The name of an action, or the keyword "all" Optionally, a single object name, or the keyword "all" If the object is present, then optionally one or more property name-value pairs in the form 'property=value'. File Processing Overview ACL files are processed line by line from the top of the file down. Group membership must be established before the group name is used in an ACL rule. Deny Mode vs. Allow Mode By default ACL files are in 'Deny Mode' and deny all actions by all users. That is, there is an implicit "acl deny all all" rule appended to the ACL rule list. In 'Deny Mode' any action by any actor is denied unless some other rule in the ACL file explicitly allows it. Administrators may change an ACL file to 'Allow Mode' by ending the ACL file with "acl allow all all". When this rule is present at then end of the ACL file then any action by any actor is allowed unless some other rule in the ACL file explictly denys it. C++ Brokers prior to release 0.16 had an optimization based on the Allow Mode or Deny Mode. In a Deny Mode ACL file all 'deny' or 'deny-log' rules are discarded. Similarly in an Allow Mode ACL file all 'allow' or 'allow-log' rules are discarded. This characteristic made specification of certain ACL rules difficult and confusing. C++ Brokers after release 0.16 do not optimize the rules based on Allow Mode or Deny Mode. All rules are kept and processed in the order specified my the ACL file. Allow rules may be mixed with Deny rules and if a rule is matched then an allow or deny decision is rendered. # Example of C++ Broker Allow Mode processing behavior group admins bob@QPID joe@QPID acl allow bob@QPID create queue acl deny admins create queue acl allow all all # Prior to release 0.16 bob is denied permission to create a queue because the # 'allow bob@QPID create queue' rule in an Allow Mode file is discarded. # Since release 0.16 bob is allowed permission to create a queue because no # rules in the file are discarded and the first allow rule controls the decision. Rule Processing Details Rules are interpreted from the top of the file down until a matching rule is obtained. The matching rule then controls the allow or deny decision. Rule Matching Details The minimum matching criteria for all ACL rules are: An actor (individually named or group member) An action An object If a rule does not match the minimum criteria then that rule does not control the ACL decision. ACL rules optionally specify object names and property values: If an object is named and/or property values are specified in an ACL rule then all of them must match to cause the rule to match. # Example of rule matching # # Using this ACL file content: (1) acl deny bob create exchange name=test durable=true passive=true (2) acl deny bob create exchange name=myEx type=direct (3) acl allow all all # # Lookup 1. id:bob action:create objectType:exchange name=test {durable=false passive=false type=direct alternate=} # # ACL Match Processing: # 1. Rule 1 passes minimum criteria with user bob, action create, and object exchange. # 2. Rule 1 matches name=test. # 3. Rule 1 does not match the rule's durable=false with the requested lookup of durable=true. # 4. Rule 1 does not control the decision and processing continues to Rule 2. # 5. Rule 2 passes minimum criteria with user bob, action create, and object exchange. # 6. Rule 2 does not match the rule's name=myEx with the requested lookup of name=test. # 7. Rule 2 does not control the decision and processing continues to Rule 3. # 8. Rule 3 matches everything and the decision is 'allow'. # # Lookup 2. id:bob action:create objectType:exchange name=myEx {durable=true passive=true type=direct alternate=} # # ACL Match Processing: # 1. Rule 1 passes minimum criteria with user bob, action create, and object exchange. # 6. Rule 1 does not match the rule's name=test with the requested lookup of name=myEx. # 4. Rule 1 does not control the decision and processing continues to Rule 2. # 5. Rule 2 passes minimum criteria with user bob, action create, and object exchange. # 2. Rule 2 matches name=myEx. # 3. Rule 2 matches the rule's type=direct with the requested lookup of type=direct. # 8. Rule 2 matches everything and the decision is 'deny'. # C++ Broker release 0.16 introduces new rule matching criteria. Certain rule properties are introduced that constrain settings from exceeding ACL minimums or maximums. When specified in an ACL allow rule these properties do not affect that rule's match determination. Rather, when the constraint is exceeded then the allow rule which is otherwise matched is converted into a deny rule. The new rule properties have no effect in deny rules. The new rule properties are: queuemaxsizelowerlimit queuemaxsizeupperlimit (alias: maxqueuesize) queuemaxcountlowerlimit queuemaxcountupperlimit (alias: maxqueuecount) # Example of ACL specifying queue size constraints # Note: for legibility this acl line has been split into multiple lines. acl allow bob@QPID create queue name=q6 queuemaxsizelowerlimit=50 queuemaxsizeupperlimit=100 queuemaxcountlowerlimit=200 queuemaxcountupperlimit=300 # # These limits come into play when a queue is created as illustrated here: queue_options = {} queue_options["qpid.max_count"] = 101 queue_options["qpid.max_size"] = 100 session.queue_declare(queue="q6", arguments=queue_options) # # When the ACL rule is processed the actor, action, object, and object name all match # and so this allow rule matches for the allow or deny decision. However, the ACL rule # is further constrained to limit 50 <= max_size <= 100 and 200 <= max_count <= 300. # Since the queue_option max_count is 101 then the size limit is violated and the # allow rule is returned with a deny decision. Validation Note: In the 0.16 C++ Broker only the following validation is performed on ACL rule files: Files are correctly formatted with respect to character sets, white space, continuation, and line length. Permissions, Actions and Objects are correctly named. Sufficient tokens are presented for each ACL rule. Any validation error is fatal and the broker is shut down. Every line in an ACL file is validated before the broker is shut down due to a validation failure. Example file: # Some groups group admin ted@QPID martin@QPID group user-consume martin@QPID ted@QPID group group2 kim@QPID user-consume rob@QPID group publisher group2 \ tom@QPID andrew@QPID debbie@QPID # Some rules acl allow carlt@QPID create exchange name=carl.* acl deny rob@QPID create queue acl allow guest@QPID bind exchange name=amq.topic routingkey=stocks.ibm.# owner=self acl allow user-consume create queue name=tmp.* acl allow publisher publish all durable=false acl allow publisher create queue name=RequestQueue acl allow consumer consume queue durable=true acl allow fred@QPID create all acl allow bob@QPID all queue acl allow admin all acl deny kim@QPID all acl allow all consume queue owner=self acl allow all bind exchange owner=self # Last (default) rule acl deny all all Design Documentation Mapping of ACL traps to action and type The C++ broker maps the ACL traps in the follow way for AMQP 0-10. The Java broker currently only performs ACLs on the AMQP connection not on management functions. This table also shows which property values are allowed to be specified for each Object-Action pair. Object Action Properties Trap C++ Trap Java Exchange Create name type alternate passive durable ExchangeHandlerImpl::declare ExchangeDeclareHandler Exchange Delete name ExchangeHandlerImpl::delete ExchangeDeleteHandler Exchange Access name ExchangeHandlerImpl::query Exchange Bind name routingkey queuename owner ExchangeHandlerImpl::bind QueueBindHandler Exchange Unbind name routingkey ExchangeHandlerImpl::unbind ExchangeUnbindHandler Exchange Access name queuename routingkey ExchangeHandlerImpl::bound Exchange Publish name routingKey SemanticState::route BasicPublishMethodHandler Queue Access name QueueHandlerImpl::query Queue Create name alternate passive durable exclusive autodelete policytype queuemaxsizelowerlimit queuemaxsizeupperlimit queuemaxcountlowerlimit queuemaxcountupperlimit QueueHandlerImpl::declare QueueDeclareHandler Queue Purge name QueueHandlerImpl::purge QueuePurgeHandler Queue Purge name Management::Queue::purge Queue Delete name QueueHandlerImpl::delete QueueDeleteHandler Queue Consume name (possibly add in future?) MessageHandlerImpl::subscribe BasicConsumeMethodHandler BasicGetMethodHandler <Object> Update   ManagementProperty::set <Object> Access   ManagementProperty::read Link Create   Management::connect Route Create   Management:: -createFederationRoute- Route Delete   Management:: -deleteFederationRoute- Virtualhost Access name TBD ConnectionOpenMethodHandler Management actions that are not explicitly given a name property it will default the name property to management method name, if the action is 'W' Action will be 'Update', if 'R' Action will be 'Access'. for example, if the mgnt method 'joinCluster' was not mapped in schema it will be mapped in ACL file as follows Object Action Property Broker Update name=joinCluster v2 ACL User Guide Writing Good/Fast ACL The file gets read top down and rule get passed based on the first match. In the following example the first rule is unnecessary. The second rule is wider than the first rule and the same result would be achieved if the first rule was removed. acl allow peter@QPID create queue name=tmp <-- unnecessary rule causes extra work. acl allow peter@QPID create queue acl deny all all By default files end with acl deny all all the mode of the ACL engine can be swapped to be allow based by putting the following at the end of the file acl allow all all Note that 'allow' based file will be a LOT faster for message transfer. This is because the AMQP specification does not allow for creating subscribes on publish, so the ACL is executed on every message transfer. Also, ACL rules using fewer properties on publish will in general be faster. Getting ACL to Log In order to get log messages from ACL actions use allow-log and deny-log for example acl allow-log john@QPID all all acl deny-log guest@QPID all all User Id / domains running with C++ broker The user-id used for ACL is taken from the connection user-id. Thus in order to use ACL the broker authentication has to be setup. i.e. (if --auth no is used in combination with ACL the broker will deny everything) The user id in the ACL file is of the form <user-id>@<domain> The Domain is configured via the SASL configuration for the broker, and the domain/realm for qpidd is set using --realm and default to 'QPID'. To load the ACL module use, load the acl module cmd line or via the config file ./src/qpidd --load-module src/.libs/acl.so The ACL plugin provides the following option '--acl-file'. If do ACL file is supplied the broker will not enforce ACL. If an ACL file name is supplied, and the file does not exist or is invalid the broker will not start. ACL Options: --acl-file FILE The policy file to load from, loaded from data dir Change Notification Preferences View Online | View Changes | Add Comment --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@qpid.apache.org For additional commands, e-mail: commits-h...@qpid.apache.org