Details

    • Type: Sub-task Sub-task
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.7
    • Component/s: Java Broker
    • Labels:
      None
    1. acl.txt
      10 kB
      Andrew Kennedy

      Activity

      Hide
      Rajith Attapattu added a comment -

      Andrew, have you had a chance to look at http://qpid.apache.org/acl.html ?
      If you have, could you please explain what improvements you would like to make ?

      Show
      Rajith Attapattu added a comment - Andrew, have you had a chance to look at http://qpid.apache.org/acl.html ? If you have, could you please explain what improvements you would like to make ?
      Hide
      Andrew Kennedy added a comment -

      Sorry for the delay in adding this...

      The changes are cosmetic, mostly, and would (admittedly) have the result of breaking Java to C++ compatibility, although C++ ACL files would remain parseable by the Java broker. The file format specification would have three types of declarations: group, acl or config, which I will describe below. Additionally, there are common features among these declarations.

      1. Whitespace is considered to be any ASCII byte with a value below 0x20, and is ignored when it occurs between tokens.
      2. Continuations using the '\' character (ASCII 0x5c) are allowed anywhere on a line, and can consist of a blank line with a continuation character as the lat non-whitespace token
      3. Comments are line-style comments, and any text after an un-quoted '#' (ASCII 0x23) are ignored, including continuations. The '#' charater may appear in a quoted string.
      4. Quoted strings consist of any ASCII inside matching pairs of ''' or '"' (ASCII 0x27 and 0x22) characters, including any otherwise special characters.
      5. Tokens are NOT case sensitive, but quoted strings ARE.
      6. The '=' (ASCII 0x3d) character is special, and is used to indicate property value assignment.
      7. Wildcards are specified using the '*' (ASCII 0x2a) character in a property value string, which may be quoted.

      The declarations are as follows, using some kind of grammar, with + and * having the usual regular expression meanings, parenthesis denote grouping and brackets denote optional elements.

      CONFIG ( <config-property> '=' <TRUE | FALSE> ) +
      GROUP <group-name> ( <username | group-name> ) +
      [ <number> ] ACL <permission> <username | group-name | ALL> <operation> [ <object-type> ( <property-name> '=' <property-value> ) * ]

      This allows a rather looser and more readable style for ACL files, while still retaining the ability to read the stricter files accepted by the C++ broker. Bear in mind that the group declarations are to be deprecated, in favour of an external directory service, using a plugin mechanism.

      The initial <number> is used to allow rulesets to be created which allow indicidual rules to be enabled and disabled using an admin interface, and an ACL file using numbered lines would be restricted to having increasing numbers per rule, although gaps would be allowed to enable rules to be inserted later, again using an admin interface. This administrative interface would also allow saving of a modified ruleset and re-loading.

      Additionally, the following operations, object types and property names are defined, some of which are not present in the C++ implementation:

      Operation: ALL, CONSUME, PUBLISH, CREATE, ACCESS, CONNECT, BIND, UNBIND, DELETE, PURGE, UPDATE, ADMIN
      ObjectType: ALL, VIRTUALHOST, QUEUE, TOPIC, EXCHANGE, BROKER, LINK, ROUTE, METHOD, USER, LOG, CONFIG, ACL
      Property: ROUTING_KEY, NAME, QUEUE_NAME, OWNER, TYPE, ALTERNATE, INTERNAL, NO_WAIT, NO_LOCAL, NO_ACK, PASSIVE, DURABLE, EXCLUSIVE, TEMPORARY, AUTO_DELETE, TCP_SESSION, REMOTE_ADDR

      There are restrictions on the combinations of Operations and ObjectTypes, as well as which Properties can be used to specify an ObjectType. I will attach a more detailed document on these restrictions, which I am working on at the moment, describing the use cases that are covered.

      Andrew.

      Show
      Andrew Kennedy added a comment - Sorry for the delay in adding this... The changes are cosmetic, mostly, and would (admittedly) have the result of breaking Java to C++ compatibility, although C++ ACL files would remain parseable by the Java broker. The file format specification would have three types of declarations: group, acl or config, which I will describe below. Additionally, there are common features among these declarations. 1. Whitespace is considered to be any ASCII byte with a value below 0x20, and is ignored when it occurs between tokens. 2. Continuations using the '\' character (ASCII 0x5c) are allowed anywhere on a line, and can consist of a blank line with a continuation character as the lat non-whitespace token 3. Comments are line-style comments, and any text after an un-quoted '#' (ASCII 0x23) are ignored, including continuations. The '#' charater may appear in a quoted string. 4. Quoted strings consist of any ASCII inside matching pairs of ''' or '"' (ASCII 0x27 and 0x22) characters, including any otherwise special characters. 5. Tokens are NOT case sensitive, but quoted strings ARE . 6. The '=' (ASCII 0x3d) character is special, and is used to indicate property value assignment. 7. Wildcards are specified using the '*' (ASCII 0x2a) character in a property value string, which may be quoted. The declarations are as follows, using some kind of grammar, with + and * having the usual regular expression meanings, parenthesis denote grouping and brackets denote optional elements. CONFIG ( <config-property> '=' <TRUE | FALSE> ) + GROUP <group-name> ( <username | group-name> ) + [ <number> ] ACL <permission> <username | group-name | ALL> <operation> [ <object-type> ( <property-name> '=' <property-value> ) * ] This allows a rather looser and more readable style for ACL files, while still retaining the ability to read the stricter files accepted by the C++ broker. Bear in mind that the group declarations are to be deprecated, in favour of an external directory service, using a plugin mechanism. The initial <number> is used to allow rulesets to be created which allow indicidual rules to be enabled and disabled using an admin interface, and an ACL file using numbered lines would be restricted to having increasing numbers per rule, although gaps would be allowed to enable rules to be inserted later, again using an admin interface. This administrative interface would also allow saving of a modified ruleset and re-loading. Additionally, the following operations, object types and property names are defined, some of which are not present in the C++ implementation: Operation: ALL, CONSUME, PUBLISH, CREATE, ACCESS, CONNECT, BIND, UNBIND, DELETE, PURGE, UPDATE, ADMIN ObjectType: ALL, VIRTUALHOST, QUEUE, TOPIC, EXCHANGE, BROKER, LINK, ROUTE, METHOD, USER, LOG, CONFIG, ACL Property: ROUTING_KEY, NAME, QUEUE_NAME, OWNER, TYPE, ALTERNATE, INTERNAL, NO_WAIT, NO_LOCAL, NO_ACK, PASSIVE, DURABLE, EXCLUSIVE, TEMPORARY, AUTO_DELETE, TCP_SESSION, REMOTE_ADDR There are restrictions on the combinations of Operations and ObjectTypes, as well as which Properties can be used to specify an ObjectType. I will attach a more detailed document on these restrictions, which I am working on at the moment, describing the use cases that are covered. Andrew.
      Hide
      Rajith Attapattu added a comment -

      My comments are marked with "RA"

      The changes are cosmetic, mostly, and would (admittedly) have the result of breaking Java to C++ compatibility, although C++ ACL files would remain parseable by the Java broker. The file format specification would have three types of declarations: group, acl or config, which I will describe below. Additionally, there are common features among these declarations.

      -------------
      RA:

      1. I'd like to emphasize again that there should not be a separate c++ and java ACL file formats. We should have one and only one ACL file format for Qpid brokers. If we agree to make changes, then both brokers would need to support it.
      There are users who are already trying to use both C++ and Java brokers (using federation) in production. Having a single file format makes life very easy here.

      2. Qpid as project is aiming to provide a consistent experience across all brokers and clients. This is a vision and a goal of this project. Individual features should be developed with this in mind.

      3. IMO having a strict format is better, as it is simple and less ambiguous, resulting in far less errors. Also rigid format is better for a security related to system to prevent people from exploiting the lenient nature of the format to exploit any gaps.
      ----------------

      1. Whitespace is considered to be any ASCII byte with a value below 0x20, and is ignored when it occurs between tokens.
      2. Continuations using the '\' character (ASCII 0x5c) are allowed anywhere on a line, and can consist of a blank line with a continuation character as the lat non-whitespace token
      ---------
      RA: Is this to improve readability? I am not sure what exactly the benefit here?
      ----------

      3. Comments are line-style comments, and any text after an un-quoted '#' (ASCII 0x23) are ignored, including continuations. The '#' charater may appear in a quoted string.
      RA: I think this is useful. We need to allow comments.

      4. Quoted strings consist of any ASCII inside matching pairs of ''' or '"' (ASCII 0x27 and 0x22) characters, including any otherwise special characters.
      5. Tokens are NOT case sensitive, but quoted strings ARE.
      6. The '=' (ASCII 0x3d) character is special, and is used to indicate property value assignment.
      7. Wildcards are specified using the '*' (ASCII 0x2a) character in a property value string, which may be quoted.

      The declarations are as follows, using some kind of grammar, with + and * having the usual regular expression meanings, parenthesis denote grouping and brackets denote optional elements.

      CONFIG ( <config-property> '=' <TRUE | FALSE> ) +
      GROUP <group-name> ( <username | group-name> ) +
      [ <number> ] ACL <permission> <username | group-name | ALL> <operation> [ <object-type> ( <property-name> '=' <property-value> ) * ]

      This allows a rather looser and more readable style for ACL files, while still retaining the ability to read the stricter files accepted by the C++ broker. Bear in mind that the group declarations are to be deprecated, in favour of an external directory service, using a plugin mechanism.

      -------------------
      RA:
      1. I don't think we should deprecate the "group" declarations. I think it's a very convenient feature and is currently used by several customers that in production.

      2. I am not opposed to having a pluggable external mechanism for configuring groups. However I am still not clear as to how these groups are tied to the authentication system. Bear in mind that the users in ACL are authenticated via our authentication mechanism. So any external mechanism used for the groups needs to be used in authentication as well. Could you pls clarify this point?

      3. I like the config option. There are several use cases that can benefit from this. I will note them down when I have a bit more time.

      4. IMO there is no point having a relaxed format for Java broker and a strict format for C++. There should be a single format for both. Some of the changes you have mentioned are sensible and useful and I don't think they break backwards compatibility. So I see no reason why they shouldn't be incorporated.

      ----------------

      The initial <number> is used to allow rulesets to be created which allow indicidual rules to be enabled and disabled using an admin interface, and an ACL file using numbered lines would be restricted to having increasing numbers per rule, although gaps would be allowed to enable rules to be inserted later, again using an admin interface. This administrative interface would also allow saving of a modified ruleset and re-loading.

      Additionally, the following operations, object types and property names are defined, some of which are not present in the C++ implementation:

      Operation: ALL, CONSUME, PUBLISH, CREATE, ACCESS, CONNECT, BIND, UNBIND, DELETE, PURGE, UPDATE, ADMIN

      -----------
      RA:

      1. What is the purpose of CONNECT ?

      2. What is the purpose of ADMIN ?

      ----------

      ObjectType: ALL, VIRTUALHOST, QUEUE, TOPIC, EXCHANGE, BROKER, LINK, ROUTE, METHOD, USER, LOG, CONFIG, ACL
      -----------
      RA:

      1. I can see the value of virtual host for the current setup, but going forward do we have virtual hosts in AMQP 1.0 ? So it worth it doing so late in the game?

      2. What is the purpose of LOG, CONFIG and ACL ?
      I think CONFIG is probably a good addition, but I'd like to understand what exactly you had in mind.

      3. Also how is LOG different from "allow-log" and "deny-log" in the current format ?

      ----------

      Property: ROUTING_KEY, NAME, QUEUE_NAME, OWNER, TYPE, ALTERNATE, INTERNAL, NO_WAIT, NO_LOCAL, NO_ACK, PASSIVE, DURABLE, EXCLUSIVE, TEMPORARY, AUTO_DELETE, TCP_SESSION, REMOTE_ADDR

      ---------------
      RA:

      1. I am not sure we need both NAME and QUEUE_NAME. Was there a specific reason ?

      2. What exactly does OWNER, INTERNAL, TEMPORARY, TCP_SESSION, REMOTE_ADDR means ?

      --------------

      There are restrictions on the combinations of Operations and ObjectTypes, as well as which Properties can be used to specify an ObjectType. I will attach a more detailed document on these restrictions, which I am working on at the moment, describing the use cases that are covered.

      Andrew.

      Show
      Rajith Attapattu added a comment - My comments are marked with "RA" The changes are cosmetic, mostly, and would (admittedly) have the result of breaking Java to C++ compatibility, although C++ ACL files would remain parseable by the Java broker. The file format specification would have three types of declarations: group, acl or config, which I will describe below. Additionally, there are common features among these declarations. ------------- RA: 1. I'd like to emphasize again that there should not be a separate c++ and java ACL file formats. We should have one and only one ACL file format for Qpid brokers. If we agree to make changes, then both brokers would need to support it. There are users who are already trying to use both C++ and Java brokers (using federation) in production. Having a single file format makes life very easy here. 2. Qpid as project is aiming to provide a consistent experience across all brokers and clients. This is a vision and a goal of this project. Individual features should be developed with this in mind. 3. IMO having a strict format is better, as it is simple and less ambiguous, resulting in far less errors. Also rigid format is better for a security related to system to prevent people from exploiting the lenient nature of the format to exploit any gaps. ---------------- 1. Whitespace is considered to be any ASCII byte with a value below 0x20, and is ignored when it occurs between tokens. 2. Continuations using the '\' character (ASCII 0x5c) are allowed anywhere on a line, and can consist of a blank line with a continuation character as the lat non-whitespace token --------- RA: Is this to improve readability? I am not sure what exactly the benefit here? ---------- 3. Comments are line-style comments, and any text after an un-quoted '#' (ASCII 0x23) are ignored, including continuations. The '#' charater may appear in a quoted string. RA: I think this is useful. We need to allow comments. 4. Quoted strings consist of any ASCII inside matching pairs of ''' or '"' (ASCII 0x27 and 0x22) characters, including any otherwise special characters. 5. Tokens are NOT case sensitive, but quoted strings ARE . 6. The '=' (ASCII 0x3d) character is special, and is used to indicate property value assignment. 7. Wildcards are specified using the '*' (ASCII 0x2a) character in a property value string, which may be quoted. The declarations are as follows, using some kind of grammar, with + and * having the usual regular expression meanings, parenthesis denote grouping and brackets denote optional elements. CONFIG ( <config-property> '=' <TRUE | FALSE> ) + GROUP <group-name> ( <username | group-name> ) + [ <number> ] ACL <permission> <username | group-name | ALL> <operation> [ <object-type> ( <property-name> '=' <property-value> ) * ] This allows a rather looser and more readable style for ACL files, while still retaining the ability to read the stricter files accepted by the C++ broker. Bear in mind that the group declarations are to be deprecated, in favour of an external directory service, using a plugin mechanism. ------------------- RA: 1. I don't think we should deprecate the "group" declarations. I think it's a very convenient feature and is currently used by several customers that in production. 2. I am not opposed to having a pluggable external mechanism for configuring groups. However I am still not clear as to how these groups are tied to the authentication system. Bear in mind that the users in ACL are authenticated via our authentication mechanism. So any external mechanism used for the groups needs to be used in authentication as well. Could you pls clarify this point? 3. I like the config option. There are several use cases that can benefit from this. I will note them down when I have a bit more time. 4. IMO there is no point having a relaxed format for Java broker and a strict format for C++. There should be a single format for both. Some of the changes you have mentioned are sensible and useful and I don't think they break backwards compatibility. So I see no reason why they shouldn't be incorporated. ---------------- The initial <number> is used to allow rulesets to be created which allow indicidual rules to be enabled and disabled using an admin interface, and an ACL file using numbered lines would be restricted to having increasing numbers per rule, although gaps would be allowed to enable rules to be inserted later, again using an admin interface. This administrative interface would also allow saving of a modified ruleset and re-loading. Additionally, the following operations, object types and property names are defined, some of which are not present in the C++ implementation: Operation: ALL, CONSUME, PUBLISH, CREATE, ACCESS, CONNECT, BIND, UNBIND, DELETE, PURGE, UPDATE, ADMIN ----------- RA: 1. What is the purpose of CONNECT ? 2. What is the purpose of ADMIN ? ---------- ObjectType: ALL, VIRTUALHOST, QUEUE, TOPIC, EXCHANGE, BROKER, LINK, ROUTE, METHOD, USER, LOG, CONFIG, ACL ----------- RA: 1. I can see the value of virtual host for the current setup, but going forward do we have virtual hosts in AMQP 1.0 ? So it worth it doing so late in the game? 2. What is the purpose of LOG, CONFIG and ACL ? I think CONFIG is probably a good addition, but I'd like to understand what exactly you had in mind. 3. Also how is LOG different from "allow-log" and "deny-log" in the current format ? ---------- Property: ROUTING_KEY, NAME, QUEUE_NAME, OWNER, TYPE, ALTERNATE, INTERNAL, NO_WAIT, NO_LOCAL, NO_ACK, PASSIVE, DURABLE, EXCLUSIVE, TEMPORARY, AUTO_DELETE, TCP_SESSION, REMOTE_ADDR --------------- RA: 1. I am not sure we need both NAME and QUEUE_NAME. Was there a specific reason ? 2. What exactly does OWNER, INTERNAL, TEMPORARY, TCP_SESSION, REMOTE_ADDR means ? -------------- There are restrictions on the combinations of Operations and ObjectTypes, as well as which Properties can be used to specify an ObjectType. I will attach a more detailed document on these restrictions, which I am working on at the moment, describing the use cases that are covered. Andrew.
      Hide
      Andrew Kennedy added a comment -

      1. I'd like to emphasize again that there should not be a separate c++ and java ACL file formats. We should have one and only one ACL file format for Qpid brokers. If we agree to make changes, then both brokers would need to support it.
      There are users who are already trying to use both C++ and Java brokers (using federation) in production. Having a single file format makes life very easy here.

      2. Qpid as project is aiming to provide a consistent experience across all brokers and clients. This is a vision and a goal of this project. Individual features should be developed with this in mind.

      3. IMO having a strict format is better, as it is simple and less ambiguous, resulting in far less errors. Also rigid format is better for a security related to system to prevent people from exploiting the lenient nature of the format to exploit any gaps.

      ADK: I agree. The 'less strict' phrasing was not the best choice of words. The file format I'm proposing still has no ambiguity, and can be defined with a strict EBNF grammar (if so desired and is simply an extension of the C++ format, i.e. any valid C++ broker ACL file is also a valid Java broker ACL file. The opposite is not true, since at the moment there are features (virtualhosts) that are not available in the C++ broker. Actually, this can be dealt with the same way the java broker deals with currently un-implemented features (routes, links) by ignoring those ACL stanzas.

      Show
      Andrew Kennedy added a comment - 1. I'd like to emphasize again that there should not be a separate c++ and java ACL file formats. We should have one and only one ACL file format for Qpid brokers. If we agree to make changes, then both brokers would need to support it. There are users who are already trying to use both C++ and Java brokers (using federation) in production. Having a single file format makes life very easy here. 2. Qpid as project is aiming to provide a consistent experience across all brokers and clients. This is a vision and a goal of this project. Individual features should be developed with this in mind. 3. IMO having a strict format is better, as it is simple and less ambiguous, resulting in far less errors. Also rigid format is better for a security related to system to prevent people from exploiting the lenient nature of the format to exploit any gaps. ADK: I agree. The 'less strict' phrasing was not the best choice of words. The file format I'm proposing still has no ambiguity, and can be defined with a strict EBNF grammar (if so desired and is simply an extension of the C++ format, i.e. any valid C++ broker ACL file is also a valid Java broker ACL file. The opposite is not true, since at the moment there are features (virtualhosts) that are not available in the C++ broker. Actually, this can be dealt with the same way the java broker deals with currently un-implemented features (routes, links) by ignoring those ACL stanzas.
      Hide
      Andrew Kennedy added a comment -

      RA: Is this to improve readability? I am not sure what exactly the benefit here?

      ADK: The whitespace and continuation definitions are to both improve readability and to make parsing simpler. I could easily restict whitespace back to the old set, but see no problem with extending it as longas it is well defined. As for continuation lines, if they are supported in one place, why not just support them everywhere, rather than the confusing (perhaps) rules about where exactly they can be placed. Every language that allows continuation characters for line breaking simply allows them anywhere and joins the two lines, ignoring the continuation character, I just wanted to follow the existing convention.

      Show
      Andrew Kennedy added a comment - RA: Is this to improve readability? I am not sure what exactly the benefit here? ADK: The whitespace and continuation definitions are to both improve readability and to make parsing simpler. I could easily restict whitespace back to the old set, but see no problem with extending it as longas it is well defined. As for continuation lines, if they are supported in one place, why not just support them everywhere, rather than the confusing (perhaps) rules about where exactly they can be placed. Every language that allows continuation characters for line breaking simply allows them anywhere and joins the two lines, ignoring the continuation character, I just wanted to follow the existing convention.
      Hide
      Andrew Kennedy added a comment -

      RA:
      1. I don't think we should deprecate the "group" declarations. I think it's a very convenient feature and is currently used by several customers that in production.

      2. I am not opposed to having a pluggable external mechanism for configuring groups. However I am still not clear as to how these groups are tied to the authentication system. Bear in mind that the users in ACL are authenticated via our authentication mechanism. So any external mechanism used for the groups needs to be used in authentication as well. Could you pls clarify this point?

      ADK: This is to allow other mechanisms, primarily directory services but also stand-alone group files, such as the unix /etc/group file. I have no problem keepin the ability to include groups in the ACL file, I would just like to have the ability to override this facility and use an external, pluggable mechanism. In many cases this will be separate from the authentication mechanism by their very nature - unix passwd and group is an obvious example, as is .htaccess and tomcat groups. We should continue discussion at QPID-2541 though.

      Show
      Andrew Kennedy added a comment - RA: 1. I don't think we should deprecate the "group" declarations. I think it's a very convenient feature and is currently used by several customers that in production. 2. I am not opposed to having a pluggable external mechanism for configuring groups. However I am still not clear as to how these groups are tied to the authentication system. Bear in mind that the users in ACL are authenticated via our authentication mechanism. So any external mechanism used for the groups needs to be used in authentication as well. Could you pls clarify this point? ADK: This is to allow other mechanisms, primarily directory services but also stand-alone group files, such as the unix /etc/group file. I have no problem keepin the ability to include groups in the ACL file, I would just like to have the ability to override this facility and use an external, pluggable mechanism. In many cases this will be separate from the authentication mechanism by their very nature - unix passwd and group is an obvious example, as is .htaccess and tomcat groups. We should continue discussion at QPID-2541 though.
      Hide
      Andrew Kennedy added a comment -

      1. What is the purpose of CONNECT ?

      ADK: An ACL that allows access to a virtual host, but no more. Only CONNECT VIRTUALHOST makes sense for this operation.

      2. What is the purpose of ADMIN ?

      2. What is the purpose of LOG, CONFIG and ACL ?
      I think CONFIG is probably a good addition, but I'd like to understand what exactly you had in mind.

      3. Also how is LOG different from "allow-log" and "deny-log" in the current format ?

      ADK: An ACL that allows JMX (or QMF) administration to take place, where the object being administered is either the BROKER (i.e. to retrieve queue names, statistics, read-only attributes and so on) or CONFIG, LOG or USER. These three are only modifiable using the admin interface, wheras the other ACL entries apply (like CREATE QUEUE) no matter how the queue is created. CONFIG grants permission to reload the security config, or edit ACL lines, LOG allows changing the log4j levels and USER grants the ability to add/delete users.

      Show
      Andrew Kennedy added a comment - 1. What is the purpose of CONNECT ? ADK: An ACL that allows access to a virtual host, but no more. Only CONNECT VIRTUALHOST makes sense for this operation. 2. What is the purpose of ADMIN ? 2. What is the purpose of LOG, CONFIG and ACL ? I think CONFIG is probably a good addition, but I'd like to understand what exactly you had in mind. 3. Also how is LOG different from "allow-log" and "deny-log" in the current format ? ADK: An ACL that allows JMX (or QMF) administration to take place, where the object being administered is either the BROKER (i.e. to retrieve queue names, statistics, read-only attributes and so on) or CONFIG, LOG or USER. These three are only modifiable using the admin interface, wheras the other ACL entries apply (like CREATE QUEUE) no matter how the queue is created. CONFIG grants permission to reload the security config, or edit ACL lines, LOG allows changing the log4j levels and USER grants the ability to add/delete users.
      Hide
      Andrew Kennedy added a comment -

      1. I can see the value of virtual host for the current setup, but going forward do we have virtual hosts in AMQP 1.0 ? So it worth it doing so late in the game?

      This is required for the Firewall plugin. Whether the Firewall plugin is required is another question entirely.

      Show
      Andrew Kennedy added a comment - 1. I can see the value of virtual host for the current setup, but going forward do we have virtual hosts in AMQP 1.0 ? So it worth it doing so late in the game? This is required for the Firewall plugin. Whether the Firewall plugin is required is another question entirely.
      Hide
      Rajith Attapattu added a comment -

      ADK: I agree. The 'less strict' phrasing was not the best choice of words. The file format I'm proposing still has no ambiguity, and can be defined with a strict EBNF grammar (if so desired and is simply an extension of the C++ format, i.e. any valid C++ broker ACL file is also a valid Java broker ACL file. The opposite is not true, since at the moment there are features (virtualhosts) that are not available in the C++ broker. Actually, this can be dealt with the same way the java broker deals with currently un-implemented features (routes, links) by ignoring those ACL stanzas.

      RA: I think we should really stop thinking in terms of a java format or c++ format. We need to focus on agreeing on a common format.
      Once we decide and agree on a format both brokers *should* be able to parse the file format.
      However each broker could ignore items that it doesn't support.

      Also when we document, we need to ensure that we position this as the "Qpid ACL format".
      Then we can go onto mention the exceptions where each broker may ignore certain entries.

      Show
      Rajith Attapattu added a comment - ADK: I agree. The 'less strict' phrasing was not the best choice of words. The file format I'm proposing still has no ambiguity, and can be defined with a strict EBNF grammar (if so desired and is simply an extension of the C++ format, i.e. any valid C++ broker ACL file is also a valid Java broker ACL file. The opposite is not true, since at the moment there are features (virtualhosts) that are not available in the C++ broker. Actually, this can be dealt with the same way the java broker deals with currently un-implemented features (routes, links) by ignoring those ACL stanzas. RA: I think we should really stop thinking in terms of a java format or c++ format. We need to focus on agreeing on a common format. Once we decide and agree on a format both brokers * should * be able to parse the file format. However each broker could ignore items that it doesn't support. Also when we document, we need to ensure that we position this as the "Qpid ACL format". Then we can go onto mention the exceptions where each broker may ignore certain entries.
      Hide
      Rajith Attapattu added a comment -

      RA: Is this to improve readability? I am not sure what exactly the benefit here?

      ADK: The whitespace and continuation definitions are to both improve readability and to make parsing simpler. I could easily restict whitespace back to the old set, but see no problem with extending it as longas it is well defined. As for continuation lines, if they are supported in one place, why not just support them everywhere, rather than the confusing (perhaps) rules about where exactly they can be placed. Every language that allows continuation characters for line breaking simply allows them anywhere and joins the two lines, ignoring the continuation character, I just wanted to follow the existing convention.

      RA: I am totally fine with the whitespace, my comment was more about continuations. Sorry for not making that clear.
      Could you perhaps provide an example of what is allowed and not allowed with the proposed changes for continuations ?

      Show
      Rajith Attapattu added a comment - RA: Is this to improve readability? I am not sure what exactly the benefit here? ADK: The whitespace and continuation definitions are to both improve readability and to make parsing simpler. I could easily restict whitespace back to the old set, but see no problem with extending it as longas it is well defined. As for continuation lines, if they are supported in one place, why not just support them everywhere, rather than the confusing (perhaps) rules about where exactly they can be placed. Every language that allows continuation characters for line breaking simply allows them anywhere and joins the two lines, ignoring the continuation character, I just wanted to follow the existing convention. RA: I am totally fine with the whitespace, my comment was more about continuations. Sorry for not making that clear. Could you perhaps provide an example of what is allowed and not allowed with the proposed changes for continuations ?
      Hide
      Rajith Attapattu added a comment -

      1. What is the purpose of CONNECT ?

      ADK: An ACL that allows access to a virtual host, but no more. Only CONNECT VIRTUALHOST makes sense for this operation.

      RA: In that case why not use "ACCESS" which is already there ?

      2. What is the purpose of ADMIN ?

      2. What is the purpose of LOG, CONFIG and ACL ?
      I think CONFIG is probably a good addition, but I'd like to understand what exactly you had in mind.

      3. Also how is LOG different from "allow-log" and "deny-log" in the current format ?

      ADK: An ACL that allows JMX (or QMF) administration to take place, where the object being administered is either the BROKER (i.e. to retrieve queue names, statistics, read-only attributes and so on) or CONFIG, LOG or USER. These three are only modifiable using the admin interface, wheras the other ACL entries apply (like CREATE QUEUE) no matter how the queue is created.

      RA: We already have a BROKER object.
      And we already have "METHOD" for QMF, which I think nicely covers JMX as well.
      If you need to query a queue name, then that is protected by the QUEUE object.

      In ACL, each object defines it's own access control list. So I didn't really understand the role of the "ACL" object. in the context you described.
      Besides ACL module does not add/modify users. That is the responsibility of the authentication mechanism defined using SASL.
      So not sure what the "USER" object is supposed to do.

      CONFIG grants permission to reload the security config, or edit ACL lines,

      RA: We need to have a mechanism to allow reloading of config files. This may include the ACL file, security config, log config etc..
      However I am wondering how much of config is going to overlap with QMF.
      For example the C++ broker is using QMF to reload the ACL file.
      So reloading of the ACL file is actually protected under the "METHOD" object.

      As I mentioned before, METHOD can cover both QMF and JMX. However I really dislike the name
      Perhaps we can have a meaningful name here. Maybe ADMIN (or MGT) instead of METHOD ?

      LOG allows changing the log4j levels and USER grants the ability to add/delete users.

      RA: Instead of using a separate top level object can we not have this under the purview of the MGT or ADMIN (previously METHOD) object and the properties to define the file name, log level etc..
      But I am also not really opposed to having a top level LOG object either.
      I'd be interested to hear opinions from a wider audience as well.

      Show
      Rajith Attapattu added a comment - 1. What is the purpose of CONNECT ? ADK: An ACL that allows access to a virtual host, but no more. Only CONNECT VIRTUALHOST makes sense for this operation. RA: In that case why not use "ACCESS" which is already there ? 2. What is the purpose of ADMIN ? 2. What is the purpose of LOG, CONFIG and ACL ? I think CONFIG is probably a good addition, but I'd like to understand what exactly you had in mind. 3. Also how is LOG different from "allow-log" and "deny-log" in the current format ? ADK: An ACL that allows JMX (or QMF) administration to take place, where the object being administered is either the BROKER (i.e. to retrieve queue names, statistics, read-only attributes and so on) or CONFIG, LOG or USER. These three are only modifiable using the admin interface, wheras the other ACL entries apply (like CREATE QUEUE) no matter how the queue is created. RA: We already have a BROKER object. And we already have "METHOD" for QMF, which I think nicely covers JMX as well. If you need to query a queue name, then that is protected by the QUEUE object. In ACL, each object defines it's own access control list. So I didn't really understand the role of the "ACL" object. in the context you described. Besides ACL module does not add/modify users. That is the responsibility of the authentication mechanism defined using SASL. So not sure what the "USER" object is supposed to do. CONFIG grants permission to reload the security config, or edit ACL lines, RA: We need to have a mechanism to allow reloading of config files. This may include the ACL file, security config, log config etc.. However I am wondering how much of config is going to overlap with QMF. For example the C++ broker is using QMF to reload the ACL file. So reloading of the ACL file is actually protected under the "METHOD" object. As I mentioned before, METHOD can cover both QMF and JMX. However I really dislike the name Perhaps we can have a meaningful name here. Maybe ADMIN (or MGT) instead of METHOD ? LOG allows changing the log4j levels and USER grants the ability to add/delete users. RA: Instead of using a separate top level object can we not have this under the purview of the MGT or ADMIN (previously METHOD) object and the properties to define the file name, log level etc.. But I am also not really opposed to having a top level LOG object either. I'd be interested to hear opinions from a wider audience as well.
      Hide
      Rajith Attapattu added a comment -

      1. I can see the value of virtual host for the current setup, but going forward do we have virtual hosts in AMQP 1.0 ? So it worth it doing so late in the game?

      I am not opposed to having a virtual host object in the ACL file as the Java broker is using that.
      The c++ broker can easily ignore it.
      My question was more about whether it's really worth spending effort on something that we know want be there for long.
      If you have customer requests for protecting virtual hosts with ACL then it is fine (All though I think this is redundant as the objects within a virtual host is covered anyways).
      But if there is no interest from the users, then I'd say don't bother.

      ADK: This is required for the Firewall plugin. Whether the Firewall plugin is required is another question entirely.

      RA: Good question, Aidan and I had discussed on the qpid dev list about using ACL to validate the IP addresses instead of maintaining a separate firewall plugin.
      The C++ broker does have an outstanding JIRA for something similar to the firewall plugin which we hope to implement using ACL.
      We were planning to have that as an optional feature to ensure backwards compatibility.

      So if you want ACL to restrict IP address you need to explicitly enable it in the ACL module.
      The config option (Not the CONFIG object) you talked about is going to be handy here.

      I am bit swamped these days, hopefully when I get some free time, I will try to put my thoughts into a wiki page to capture the requirements and share some ideas with you.
      Perhaps then we can open some more concrete JIRA's to focus on those individual areas.

      Show
      Rajith Attapattu added a comment - 1. I can see the value of virtual host for the current setup, but going forward do we have virtual hosts in AMQP 1.0 ? So it worth it doing so late in the game? I am not opposed to having a virtual host object in the ACL file as the Java broker is using that. The c++ broker can easily ignore it. My question was more about whether it's really worth spending effort on something that we know want be there for long. If you have customer requests for protecting virtual hosts with ACL then it is fine (All though I think this is redundant as the objects within a virtual host is covered anyways). But if there is no interest from the users, then I'd say don't bother. ADK: This is required for the Firewall plugin. Whether the Firewall plugin is required is another question entirely. RA: Good question, Aidan and I had discussed on the qpid dev list about using ACL to validate the IP addresses instead of maintaining a separate firewall plugin. The C++ broker does have an outstanding JIRA for something similar to the firewall plugin which we hope to implement using ACL. We were planning to have that as an optional feature to ensure backwards compatibility. So if you want ACL to restrict IP address you need to explicitly enable it in the ACL module. The config option (Not the CONFIG object) you talked about is going to be handy here. I am bit swamped these days, hopefully when I get some free time, I will try to put my thoughts into a wiki page to capture the requirements and share some ideas with you. Perhaps then we can open some more concrete JIRA's to focus on those individual areas.
      Hide
      Andrew Kennedy added a comment -

      1. What is the purpose of CONNECT ?

      ADK: An ACL that allows access to a virtual host, but no more. Only CONNECT VIRTUALHOST makes sense for this operation.

      RA: In that case why not use "ACCESS" which is already there ?

      ADK: I just checked, and it turns out I am using ACCESS, exactly as you say. I have removed CONNECT now.

      Show
      Andrew Kennedy added a comment - 1. What is the purpose of CONNECT ? ADK: An ACL that allows access to a virtual host, but no more. Only CONNECT VIRTUALHOST makes sense for this operation. RA: In that case why not use "ACCESS" which is already there ? ADK: I just checked, and it turns out I am using ACCESS, exactly as you say. I have removed CONNECT now.
      Hide
      Carl Trieloff added a comment - - edited

      Is ADMIN not just a group of users with a specifc set of permissions assigned?

      Is CONNECT not just allow access virtualhost ?

      I think LOG is already covered with METHOD, maybe we should walk through an example for JMX admin and QMF Admin and see if it covers all the cases that are being thought about. If not we should add those to the METHOD call.

      " LOG allows changing the log4j levels and USER grants the ability to add/delete users. " Is use not a broker tangental concept. I know Java broker supports a user create call. In my view with QMF, this should be modeled with a QMF user schema and then if that object is supplied by the broker or something external it makes no diff.

      Then all the permissions can be applied to all the methods on that schema using the METHOD object. This would keep things 100% consistent. i.e. controlling setting log level, adding users etc all sound like METHOD permissions.

      Carl.

      Show
      Carl Trieloff added a comment - - edited Is ADMIN not just a group of users with a specifc set of permissions assigned? Is CONNECT not just allow access virtualhost ? I think LOG is already covered with METHOD, maybe we should walk through an example for JMX admin and QMF Admin and see if it covers all the cases that are being thought about. If not we should add those to the METHOD call. " LOG allows changing the log4j levels and USER grants the ability to add/delete users. " Is use not a broker tangental concept. I know Java broker supports a user create call. In my view with QMF, this should be modeled with a QMF user schema and then if that object is supplied by the broker or something external it makes no diff. Then all the permissions can be applied to all the methods on that schema using the METHOD object. This would keep things 100% consistent. i.e. controlling setting log level, adding users etc all sound like METHOD permissions. Carl.
      Hide
      Andrew Kennedy added a comment -

      RA: We need to have a mechanism to allow reloading of config files. This may include the ACL file, security config, log config etc..
      However I am wondering how much of config is going to overlap with QMF.
      For example the C++ broker is using QMF to reload the ACL file.
      So reloading of the ACL file is actually protected under the "METHOD" object.

      As I mentioned before, METHOD can cover both QMF and JMX. However I really dislike the name
      Perhaps we can have a meaningful name here. Maybe ADMIN (or MGT) instead of METHOD ?

      LOG allows changing the log4j levels and USER grants the ability to add/delete users.

      RA: Instead of using a separate top level object can we not have this under the purview of the MGT or ADMIN (previously METHOD) object and the properties to define the file name, log level etc..
      But I am also not really opposed to having a top level LOG object either.
      I'd be interested to hear opinions from a wider audience as well.

      ADK:
      FYI, there is no ACL object, that may have been a typo.

      I don't have any preference between ADMIN or MANGE, but I prefer both of those to METHOD. Also, to me this is an operation and the object types I suggested would then allow ACL lines like this:

      ACL ALLOW admin ADMIN BROKER # allow JMX/QMF access to read-only management attributes on the broker
      ACL ALLOW admin ADMIN CONFIG # allow JMX/QMF administration of configuration file reloading
      ACL ALLOW admin ADMIN LOG # allow JMX/QMF log level administration
      ACL ALLOW admin ADMIN USER # allow JMX/QMF user administration

      Show
      Andrew Kennedy added a comment - RA: We need to have a mechanism to allow reloading of config files. This may include the ACL file, security config, log config etc.. However I am wondering how much of config is going to overlap with QMF. For example the C++ broker is using QMF to reload the ACL file. So reloading of the ACL file is actually protected under the "METHOD" object. As I mentioned before, METHOD can cover both QMF and JMX. However I really dislike the name Perhaps we can have a meaningful name here. Maybe ADMIN (or MGT) instead of METHOD ? LOG allows changing the log4j levels and USER grants the ability to add/delete users. RA: Instead of using a separate top level object can we not have this under the purview of the MGT or ADMIN (previously METHOD) object and the properties to define the file name, log level etc.. But I am also not really opposed to having a top level LOG object either. I'd be interested to hear opinions from a wider audience as well. ADK: FYI, there is no ACL object, that may have been a typo. I don't have any preference between ADMIN or MANGE, but I prefer both of those to METHOD. Also, to me this is an operation and the object types I suggested would then allow ACL lines like this: ACL ALLOW admin ADMIN BROKER # allow JMX/QMF access to read-only management attributes on the broker ACL ALLOW admin ADMIN CONFIG # allow JMX/QMF administration of configuration file reloading ACL ALLOW admin ADMIN LOG # allow JMX/QMF log level administration ACL ALLOW admin ADMIN USER # allow JMX/QMF user administration
      Hide
      Andrew Kennedy added a comment -

      I couldn't find any documentation of the METHOD object, and it is not listed on the ACL web page. Could someone list the way this is currently used, and give some example ACL lines to illustrate?

      Cheers,
      Andrew.

      Show
      Andrew Kennedy added a comment - I couldn't find any documentation of the METHOD object, and it is not listed on the ACL web page. Could someone list the way this is currently used, and give some example ACL lines to illustrate? Cheers, Andrew.
      Hide
      Carl Trieloff added a comment -

      RA: We need to have a mechanism to allow reloading of config files. This may include the ACL file, security config, log config etc..
      However I am wondering how much of config is going to overlap with QMF.

      On C++ side is is done like this:

      <class name="Acl">
      <property name="brokerRef" type="objId" references="org.apache.qpid.broker:Broker" access="RO" index="y" parentRef="y"/>
      <property name="policyFile" type="sstr" access="RO" desc="Name of the policy file"/>
      <property name="enforcingAcl" type="bool" access="RO" desc="Currently Enforcing ACL"/>
      <property name="transferAcl" type="bool" access="RO" desc="Any transfer ACL rules in force"/>
      <property name="lastAclLoad" type="absTime" access="RO" desc="Timestamp of last successful load of ACL"/>
      <statistic name="aclDenyCount" type="count64" unit="request" desc="Number of ACL requests denied"/>

      <method name="reloadACLFile" desc="Reload the ACL file"/>
      </class>

      Then the normal ACL action perissions are applied to the method, allowing you to set permissions of who may reload the ACL's. Reason it is 'METHOD' is that it ACL's applied to QMF methods....

      -->

      I don't have any preference between ADMIN or MANGE, but I prefer both of those to METHOD. Also, to me this is an operation and the object types I suggested would then allow ACL lines like this:

      ACL ALLOW admin ADMIN BROKER # allow JMX/QMF access to read-only management attributes on the broker
      ACL ALLOW admin ADMIN CONFIG # allow JMX/QMF administration of configuration file reloading
      ACL ALLOW admin ADMIN LOG # allow JMX/QMF log level administration
      ACL ALLOW admin ADMIN USER # allow JMX/QMF user administration

      <--

      For example

      group admin (......)
      acl allow admin method all # allow admin group access to all QMF / JMX methods.
      acl allow admin access all # equivalent of your LOG level statement.
      acl allow admin update method reloadACLFile # allow admin group to update acl file.

      I believe they are all covered already.

      Carl.

      Show
      Carl Trieloff added a comment - RA: We need to have a mechanism to allow reloading of config files. This may include the ACL file, security config, log config etc.. However I am wondering how much of config is going to overlap with QMF. On C++ side is is done like this: <class name="Acl"> <property name="brokerRef" type="objId" references="org.apache.qpid.broker:Broker" access="RO" index="y" parentRef="y"/> <property name="policyFile" type="sstr" access="RO" desc="Name of the policy file"/> <property name="enforcingAcl" type="bool" access="RO" desc="Currently Enforcing ACL"/> <property name="transferAcl" type="bool" access="RO" desc="Any transfer ACL rules in force"/> <property name="lastAclLoad" type="absTime" access="RO" desc="Timestamp of last successful load of ACL"/> <statistic name="aclDenyCount" type="count64" unit="request" desc="Number of ACL requests denied"/> <method name="reloadACLFile" desc="Reload the ACL file"/> </class> Then the normal ACL action perissions are applied to the method, allowing you to set permissions of who may reload the ACL's. Reason it is 'METHOD' is that it ACL's applied to QMF methods.... --> I don't have any preference between ADMIN or MANGE, but I prefer both of those to METHOD. Also, to me this is an operation and the object types I suggested would then allow ACL lines like this: ACL ALLOW admin ADMIN BROKER # allow JMX/QMF access to read-only management attributes on the broker ACL ALLOW admin ADMIN CONFIG # allow JMX/QMF administration of configuration file reloading ACL ALLOW admin ADMIN LOG # allow JMX/QMF log level administration ACL ALLOW admin ADMIN USER # allow JMX/QMF user administration <-- For example group admin (......) acl allow admin method all # allow admin group access to all QMF / JMX methods. acl allow admin access all # equivalent of your LOG level statement. acl allow admin update method reloadACLFile # allow admin group to update acl file. I believe they are all covered already. Carl.
      Hide
      Rajith Attapattu added a comment -

      I see that Carl had already put up an example.

      Andrew could you also put up a wiki page with your proposals and use examples.
      You could then post the link in the description section.
      That will help a lot to avoid going back and forth to clarify certain points.
      Also it will help folks who will join the discussion mid way through.

      Show
      Rajith Attapattu added a comment - I see that Carl had already put up an example. Andrew could you also put up a wiki page with your proposals and use examples. You could then post the link in the description section. That will help a lot to avoid going back and forth to clarify certain points. Also it will help folks who will join the discussion mid way through.
      Hide
      Andrew Kennedy added a comment -

      acl allow admin admin log # allow JMX/QMF log level administration

      This means that the log4j logger's level is able to be changed from, e.g. INFO to DEBUG, or a new logging configuration file can be loaded, I don't believe it is equivalent to:

      acl allow admin access all

      Also, you use METHOD as both an object and an operation - it isn't clear what the difference between, say, access method and update method would be?

      acl allow admin method all # should there be an update or an access before the method?
      acl allow admin update method reloadACLFile

      Would these not be clearer as:

      acl allow admin access method name=* # access to all methods
      acl allow admin access method name=reloadACLFile # access to a single method

      or even:

      acl allow admin manage broker method=*
      acl allow admin manage broker method=reloadACLFile

      I will update the document I'm writing with the results of this discussion and post a link.

      Show
      Andrew Kennedy added a comment - acl allow admin admin log # allow JMX/QMF log level administration This means that the log4j logger's level is able to be changed from, e.g. INFO to DEBUG, or a new logging configuration file can be loaded, I don't believe it is equivalent to: acl allow admin access all Also, you use METHOD as both an object and an operation - it isn't clear what the difference between, say, access method and update method would be? acl allow admin method all # should there be an update or an access before the method? acl allow admin update method reloadACLFile Would these not be clearer as: acl allow admin access method name=* # access to all methods acl allow admin access method name=reloadACLFile # access to a single method or even: acl allow admin manage broker method=* acl allow admin manage broker method=reloadACLFile I will update the document I'm writing with the results of this discussion and post a link.
      Hide
      Carl Trieloff added a comment -

      I think the thread can be summed as follows:

      • The acl v2 mechinism can most likely handle all if not all the cases, (maybe a few minor things are missing).
      • From the Java side, they have a few defined (groups/roles) with specific predefined permissions.

      I think the debate will come down to – should we include a set of 'qpid-defined' named roles with permissions set. The approach on the C++ side has been to allow the user to create what he needs. But having a few predefined groups (even if just shipped in the default acl file) that may be meaningful.

      Carl.

      Show
      Carl Trieloff added a comment - I think the thread can be summed as follows: The acl v2 mechinism can most likely handle all if not all the cases, (maybe a few minor things are missing). From the Java side, they have a few defined (groups/roles) with specific predefined permissions. I think the debate will come down to – should we include a set of 'qpid-defined' named roles with permissions set. The approach on the C++ side has been to allow the user to create what he needs. But having a few predefined groups (even if just shipped in the default acl file) that may be meaningful. Carl.
      Hide
      Carl Trieloff added a comment -

      I miss-typed the one example, method is an object.

      I really don't get why you keep putting in 'manage' – what does that mean - access, update, delete ? or all of them?

      Carl.

      Show
      Carl Trieloff added a comment - I miss-typed the one example, method is an object. I really don't get why you keep putting in 'manage' – what does that mean - access, update, delete ? or all of them? Carl.
      Hide
      Martin Ritchie added a comment -

      Carl,

      In your reloadACLFile example are you not missing the property name?
      According to the ACLv2 spec on the wiki that, we both worked on, your example should be more like:

      acl allow admin update method name=reloadACLFile # allow admin group to update acl file.

      Wiki Spec for ACLv2
      acl permission

      {<group-name>|<user-name>|"all"}

      {action|"all"}

      [object|"all"] [property=<property-value>]

      Does the C++ broker allow this line?
      acl allow admin update method reloadACLFile

      Show
      Martin Ritchie added a comment - Carl, In your reloadACLFile example are you not missing the property name? According to the ACLv2 spec on the wiki that, we both worked on, your example should be more like: acl allow admin update method name=reloadACLFile # allow admin group to update acl file. Wiki Spec for ACLv2 acl permission {<group-name>|<user-name>|"all"} {action|"all"} [object|"all"] [property=<property-value>] Does the C++ broker allow this line? acl allow admin update method reloadACLFile
      Hide
      Andrew Kennedy added a comment -

      The reason I used MANAGE was that the type of operation is not determined by the object or the operation, but by the name of the method, so the operation token has no meaning.

      This would also interfere with the ability to add e.g. CREATE QUEUE permission and have that be meaningful when accessing the broker via the management interfaces. I am more in favour of abandoning the METHOD based mechanism, in favour of enumerating the objects that can be accessed via the management interfaces and adding ACCESS and UPDATE, possibly ADMIN/MANAGE operations to them where possible.

      Show
      Andrew Kennedy added a comment - The reason I used MANAGE was that the type of operation is not determined by the object or the operation, but by the name of the method, so the operation token has no meaning. This would also interfere with the ability to add e.g. CREATE QUEUE permission and have that be meaningful when accessing the broker via the management interfaces. I am more in favour of abandoning the METHOD based mechanism, in favour of enumerating the objects that can be accessed via the management interfaces and adding ACCESS and UPDATE, possibly ADMIN/MANAGE operations to them where possible.
      Hide
      Andrew Kennedy added a comment -

      Forgot to add this before. I have updated it with some details of the discussion.

      Show
      Andrew Kennedy added a comment - Forgot to add this before. I have updated it with some details of the discussion.
      Hide
      Andrew Kennedy added a comment -

      Missed this, too:

      RA: 1. I am not sure we need both NAME and QUEUE_NAME. Was there a specific reason ?

      ADK: NAME is used as the name of the object specified in the rule. When binding a queue to an exchange the queue name is set as QUEUE_NAME as well.

      RA: 2. What exactly does OWNER, INTERNAL, TEMPORARY, TCP_SESSION, REMOTE_ADDR means ?

      ADK: OWNER is queue owner, INTERNAL is a property referenced when creating exchanges, TEMPORARY is a synonym for AUTO_DELETE. Actually, TCP_SESSION and REMOTE_ADDR are not require.

      Show
      Andrew Kennedy added a comment - Missed this, too: RA: 1. I am not sure we need both NAME and QUEUE_NAME. Was there a specific reason ? ADK: NAME is used as the name of the object specified in the rule. When binding a queue to an exchange the queue name is set as QUEUE_NAME as well. RA: 2. What exactly does OWNER, INTERNAL, TEMPORARY, TCP_SESSION, REMOTE_ADDR means ? ADK: OWNER is queue owner, INTERNAL is a property referenced when creating exchanges, TEMPORARY is a synonym for AUTO_DELETE. Actually, TCP_SESSION and REMOTE_ADDR are not require.
      Hide
      Andrew Kennedy added a comment -

      correct file

      Show
      Andrew Kennedy added a comment - correct file
      Hide
      Carl Trieloff added a comment -

      Martin,

      Yes, I just sudo'ed them out from memory. If you want me to update them to be precise, I can do that.

      Andrew,

      RA: 1. I am not sure we need both NAME and QUEUE_NAME. Was there a specific reason ?

      For acl on Bindings. (acl for bind / unbind)

      NAME is the exchange name
      (make_pair(acl::PROP_QUEUENAME, queueName)); ---- QUEUENAME is the queue name
      t(make_pair(acl::PROP_ROUTINGKEY, routingKey));

      in regards to OWNER, INTERNAL, TEMPORARY, TCP_SESSION, REMOTE_ADDR – I don't see most these in the source code, where
      did you get them from ?? It might be from when Aidan was working ACLv2 for the Java broker? or from a Acl patch yet committed (Rajith?)

      Here is the full list supported currently by the C++ code base from AclModle.h

      enum ObjectType

      {OBJ_QUEUE, OBJ_EXCHANGE, OBJ_BROKER, OBJ_LINK, OBJ_METHOD, OBJECTSIZE}

      ; // OBJECTSIZE must be last in list
      enum Action

      {ACT_CONSUME, ACT_PUBLISH, ACT_CREATE, ACT_ACCESS, ACT_BIND, ACT_UNBIND, ACT_DELETE, ACT_PURGE, ACT_UPDATE, ACTIONSIZE}

      ; // ACTIONSIZE must be last in list
      enum Property

      {PROP_NAME, PROP_DURABLE, PROP_OWNER, PROP_ROUTINGKEY, PROP_PASSIVE, PROP_AUTODELETE, PROP_EXCLUSIVE, PROP_TYPE, PROP_ALTERNATE, PROP_QUEUENAME, PROP_SCHEMAPACKAGE, PROP_SCHEMACLASS, PROP_POLICYTYPE, PROP_MAXQUEUESIZE, PROP_MAXQUEUECOUNT}

      ;
      enum AclResult

      {ALLOW, ALLOWLOG, DENY, DENYLOG}

      ;

      note OBJECTSIZE ACTIONSIZE are not types, just part of the parser code.

      Carl.

      Show
      Carl Trieloff added a comment - Martin, Yes, I just sudo'ed them out from memory. If you want me to update them to be precise, I can do that. Andrew, RA: 1. I am not sure we need both NAME and QUEUE_NAME. Was there a specific reason ? For acl on Bindings. (acl for bind / unbind) NAME is the exchange name (make_pair(acl::PROP_QUEUENAME, queueName)); ---- QUEUENAME is the queue name t(make_pair(acl::PROP_ROUTINGKEY, routingKey)); in regards to OWNER, INTERNAL, TEMPORARY, TCP_SESSION, REMOTE_ADDR – I don't see most these in the source code, where did you get them from ?? It might be from when Aidan was working ACLv2 for the Java broker? or from a Acl patch yet committed (Rajith?) Here is the full list supported currently by the C++ code base from AclModle.h enum ObjectType {OBJ_QUEUE, OBJ_EXCHANGE, OBJ_BROKER, OBJ_LINK, OBJ_METHOD, OBJECTSIZE} ; // OBJECTSIZE must be last in list enum Action {ACT_CONSUME, ACT_PUBLISH, ACT_CREATE, ACT_ACCESS, ACT_BIND, ACT_UNBIND, ACT_DELETE, ACT_PURGE, ACT_UPDATE, ACTIONSIZE} ; // ACTIONSIZE must be last in list enum Property {PROP_NAME, PROP_DURABLE, PROP_OWNER, PROP_ROUTINGKEY, PROP_PASSIVE, PROP_AUTODELETE, PROP_EXCLUSIVE, PROP_TYPE, PROP_ALTERNATE, PROP_QUEUENAME, PROP_SCHEMAPACKAGE, PROP_SCHEMACLASS, PROP_POLICYTYPE, PROP_MAXQUEUESIZE, PROP_MAXQUEUECOUNT} ; enum AclResult {ALLOW, ALLOWLOG, DENY, DENYLOG} ; note OBJECTSIZE ACTIONSIZE are not types, just part of the parser code. Carl.
      Hide
      Carl Trieloff added a comment -

      Rajith,

      I don't see PROP_OWNER actually used anywhere on the code base, can that be removed?

      Then for IP Whitelisting, what props does that patch add?

      Carl.

      Show
      Carl Trieloff added a comment - Rajith, I don't see PROP_OWNER actually used anywhere on the code base, can that be removed? Then for IP Whitelisting, what props does that patch add? Carl.
      Hide
      Andrew Kennedy added a comment -

      PROP_SCHEMAPACKAGE, PROP_SCHEMACLASS, PROP_POLICYTYPE, PROP_MAXQUEUESIZE, PROP_MAXQUEUECOUNT

      Can someone explain what these do, please?

      Also, regarding OWNER, this has meaning with the Java broker, so should be kept (perhaps unused) for symmetry between formats.

      ADK.

      Show
      Andrew Kennedy added a comment - PROP_SCHEMAPACKAGE, PROP_SCHEMACLASS, PROP_POLICYTYPE, PROP_MAXQUEUESIZE, PROP_MAXQUEUECOUNT Can someone explain what these do, please? Also, regarding OWNER, this has meaning with the Java broker, so should be kept (perhaps unused) for symmetry between formats. ADK.
      Hide
      Carl Trieloff added a comment -

      PROP_MAXQUEUESIZE, PROP_MAXQUEUECOUNT — queue depth on queue creation via ACL. used by selfservice users who want users to be able to declare a queue but only get a pre-defined or less queue size.

      package and class refer to QMF, so you can scope ACL to any QMF method.

      What is OWNER used for in the Java broker?

      Carl.

      Show
      Carl Trieloff added a comment - PROP_MAXQUEUESIZE, PROP_MAXQUEUECOUNT — queue depth on queue creation via ACL. used by selfservice users who want users to be able to declare a queue but only get a pre-defined or less queue size. package and class refer to QMF, so you can scope ACL to any QMF method. What is OWNER used for in the Java broker? Carl.
      Hide
      Marnie McCormack added a comment -

      Proposal discussed with community, esp Rajith & Carl - see doc links on parent JIRA for detailed proposal output.

      Show
      Marnie McCormack added a comment - Proposal discussed with community, esp Rajith & Carl - see doc links on parent JIRA for detailed proposal output.
      Hide
      Rajith Attapattu added a comment -

      Marnie,

      All though we discussed, I do not think we agreed on a concrete proposal yet.
      I believe there are still some open questions that didn't quite get resolved.

      I am also working on a proposal which I am hoping to get out by tomorrow.
      So I'd appreciate if we keep this JIRA open until we get some sort of agreement.

      Regards,

      Rajith

      Show
      Rajith Attapattu added a comment - Marnie, All though we discussed, I do not think we agreed on a concrete proposal yet. I believe there are still some open questions that didn't quite get resolved. I am also working on a proposal which I am hoping to get out by tomorrow. So I'd appreciate if we keep this JIRA open until we get some sort of agreement. Regards, Rajith

        People

        • Assignee:
          Unassigned
          Reporter:
          Andrew Kennedy
        • Votes:
          0 Vote for this issue
          Watchers:
          0 Start watching this issue

          Dates

          • Created:
            Updated:
            Resolved:

            Development