Details

    • Type: Sub-task Sub-task
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.5.0
    • Component/s: master, tserver
    • Labels:
      None

      Description

      The built-in user management functionality should be phased out, in favor of the pluggable authentication model. Any user-management functions that apply to a particular implementation of an authentication should be handled within that implementation, and not within Accumulo's core.

      This should reduce the complexity of the overall user model.

      A transition plan should be established for the prior ZKAuthenticator implementation for usernames and passwords. The former APIs for user management should continue to work as is, and pass through to the former implementation, but any new APIs for user management should not be introduced to the core (like in SecurityOperations, the shell, and 'accumulo init'), because that introduces complexity and essentially establishes a guarantee that Accumulo will handle user management for arbitrary authentication systems... which I don't think we can do generically.

        Issue Links

          Activity

          Hide
          John Vines added a comment -

          I like it, but I do worry about the complexity for new users in having to use different interfaces for setting up the users of a system vs. using the system

          Show
          John Vines added a comment - I like it, but I do worry about the complexity for new users in having to use different interfaces for setting up the users of a system vs. using the system
          Hide
          Christopher Tubbs added a comment -

          After thinking about this some more, I think that the most intuitive transition to supporting alternate authentication schemes is to support "local" users first, and then remote users (through pluggable authentication) second. By "local" users, I mean local to the instance, using our built-in user management that existed in 1.4 and earlier. This is similar to how local users in Linux are authenticated prior to remote (NIS, LDAP, etc.) users are.

          The reason I think this is the best way to go is for several reasons. The first is because it is the most intuitive transition, in terms of the API, because the existing user management in SecurityOperations does not need to change much. At the most, it might change to say something like "createLocalUser" instead of "createUser". I strongly think this is the least intrusive change we can do to support external authentication.

          The second reason I think this is better is the upgrade process is smooth, because the existing "local" users transition seamlessly, without any change in behavior.

          A third reason I think this is better, is because those users who do not wish to use an external authentication system, are hardly affected at all, but we can still satisfy all the use cases of an external authentication system.

          This is also better for initialization, because the init system would exactly as it had in previous versions... setting the root password (for the local root user) only.

          The way this would work is that on the server side, credentials are checked against the local authentication system first, before checking them against the external authentication system that is configured. (I realize that in Linux, the order of these are configurable, but I think it's fine to make the order always local first, as that's the most common configuration in Linux; if we need the feature to change the order, it can be added as a feature later; right now, we just need to polish up and solidify the behavior and API of the new pluggable authentication stuff that was added for the 1.5.0 release).

          Show
          Christopher Tubbs added a comment - After thinking about this some more, I think that the most intuitive transition to supporting alternate authentication schemes is to support "local" users first, and then remote users (through pluggable authentication) second. By "local" users, I mean local to the instance, using our built-in user management that existed in 1.4 and earlier. This is similar to how local users in Linux are authenticated prior to remote (NIS, LDAP, etc.) users are. The reason I think this is the best way to go is for several reasons. The first is because it is the most intuitive transition, in terms of the API, because the existing user management in SecurityOperations does not need to change much. At the most, it might change to say something like "createLocalUser" instead of "createUser". I strongly think this is the least intrusive change we can do to support external authentication. The second reason I think this is better is the upgrade process is smooth, because the existing "local" users transition seamlessly, without any change in behavior. A third reason I think this is better, is because those users who do not wish to use an external authentication system, are hardly affected at all, but we can still satisfy all the use cases of an external authentication system. This is also better for initialization, because the init system would exactly as it had in previous versions... setting the root password (for the local root user) only. The way this would work is that on the server side, credentials are checked against the local authentication system first, before checking them against the external authentication system that is configured. (I realize that in Linux, the order of these are configurable, but I think it's fine to make the order always local first, as that's the most common configuration in Linux; if we need the feature to change the order, it can be added as a feature later; right now, we just need to polish up and solidify the behavior and API of the new pluggable authentication stuff that was added for the 1.5.0 release).
          Hide
          David Medinets added a comment -

          Can we use Tomcat for inspiration? Too naive?

          Show
          David Medinets added a comment - Can we use Tomcat for inspiration? Too naive?
          Hide
          John Vines added a comment -

          I like it, Christopher Tubbs. Do you basically see it as a hardcoded ZKAuthenticator/Authorizor/PermHandler and then the Authent/Author/PermHandler have an option for nil? Or something else?

          Show
          John Vines added a comment - I like it, Christopher Tubbs . Do you basically see it as a hardcoded ZKAuthenticator/Authorizor/PermHandler and then the Authent/Author/PermHandler have an option for nil? Or something else?
          Hide
          Christopher Tubbs added a comment -

          David Medinets - In what way? I don't know a lot about Tomcat's authentication. The model I'm working from is that of the basic Windows/Linux/Mac users, as far as behavior, keeping as much of John Vines' stuff in place, while minimizing the changes from 1.4 and earlier. If there's something specific we can borrow from Tomcat to make the API more intuitive, I'd love to, and am open to recommendations.

          John Vines - I'm thinking that whatever component handles the "local" or "internal" users for authentication, it will be baked in by devs, not by configuration. Any configured authentication plugin would be for "remote" or "external" users. The built-in should behave just like the configured one for external users (makes it easier on us developers), but given priority by the ClientServiceHandler and checked first. As for the Authorizor/PermHandler... I'm thinking those are entirely pluggable, as you have them now, with a default configuration. For the default Authenticator, it'd basically be an AlwaysReject sort of thing (so only local users are allowed).

          A few more thoughts on the Authorizor/PermHandler: these are essentially dumb storage, pluggable. They don't really need to do logic, so much as store attributes for a user (at least, from their respective APIs, that's how we can safely think of them). I think some things may need to be done make that more obvious (rename the interface to UserAuthorizationStorage/UserPermissionStorage or similar... though not really a fan of that idea, as it's not as "elegant" as the current naming scheme).

          Show
          Christopher Tubbs added a comment - David Medinets - In what way? I don't know a lot about Tomcat's authentication. The model I'm working from is that of the basic Windows/Linux/Mac users, as far as behavior, keeping as much of John Vines' stuff in place, while minimizing the changes from 1.4 and earlier. If there's something specific we can borrow from Tomcat to make the API more intuitive, I'd love to, and am open to recommendations. John Vines - I'm thinking that whatever component handles the "local" or "internal" users for authentication, it will be baked in by devs, not by configuration. Any configured authentication plugin would be for "remote" or "external" users. The built-in should behave just like the configured one for external users (makes it easier on us developers), but given priority by the ClientServiceHandler and checked first. As for the Authorizor/PermHandler... I'm thinking those are entirely pluggable, as you have them now, with a default configuration. For the default Authenticator, it'd basically be an AlwaysReject sort of thing (so only local users are allowed). A few more thoughts on the Authorizor/PermHandler: these are essentially dumb storage, pluggable. They don't really need to do logic, so much as store attributes for a user (at least, from their respective APIs, that's how we can safely think of them). I think some things may need to be done make that more obvious (rename the interface to UserAuthorizationStorage/UserPermissionStorage or similar... though not really a fan of that idea, as it's not as "elegant" as the current naming scheme).
          Hide
          Christopher Tubbs added a comment -

          I'm also a bit concerned about the interaction between these 3 independently configurable components when it comes to synchronizing their storage of user attributes.

          Before, when everything was a single interface (even though it wasn't yet configurable by users), it was obvious how to deal with stored permissions/authorizations when a user was created/deleted, but now... it's not so obvious, and could result in elevated access if user principals are re-used or authentication systems are swapped, but authorizations/permissions storage stays the same without resetting its storage.

          One argument is that it is the responsibility of the admin configuring the system to choose components that work well together. Another is to delegate this responsibility to a developer responsible for developing a single plugin that leverages the 3 functions of user access into a cohesive plugin (I prefer this, because it's easier to configure, and puts less burden on system admins for proper configuration to get expected security guarantees).

          I'm not sure this should be changed at this time... I think the existing, independently configurable components is fine for now, but the concern of stale user principals should be addressed as a part of the user-management changes that have already been done and those that are done as part of this ticket.

          This was brought up a little bit on the ACCUMULO-259 ticket, and I see that a "compatibleWith" concept was implemented to address resetting user permissions (probably as a result of that conversation), so I want to comment on that, too: I'm not sure I like that idea as much as a single configurable plugin instead of 3, because it creates interleaved dependencies on components that should really be independent. However, we can add a resetPermissions(user) and resetAuthorizations(user) to their respective components, so that at least authenticator plugins have the ability to reset these things when users are deleted if they want to.

          Show
          Christopher Tubbs added a comment - I'm also a bit concerned about the interaction between these 3 independently configurable components when it comes to synchronizing their storage of user attributes. Before, when everything was a single interface (even though it wasn't yet configurable by users), it was obvious how to deal with stored permissions/authorizations when a user was created/deleted, but now... it's not so obvious, and could result in elevated access if user principals are re-used or authentication systems are swapped, but authorizations/permissions storage stays the same without resetting its storage. One argument is that it is the responsibility of the admin configuring the system to choose components that work well together. Another is to delegate this responsibility to a developer responsible for developing a single plugin that leverages the 3 functions of user access into a cohesive plugin (I prefer this, because it's easier to configure, and puts less burden on system admins for proper configuration to get expected security guarantees). I'm not sure this should be changed at this time... I think the existing, independently configurable components is fine for now, but the concern of stale user principals should be addressed as a part of the user-management changes that have already been done and those that are done as part of this ticket. This was brought up a little bit on the ACCUMULO-259 ticket, and I see that a "compatibleWith" concept was implemented to address resetting user permissions (probably as a result of that conversation), so I want to comment on that, too: I'm not sure I like that idea as much as a single configurable plugin instead of 3, because it creates interleaved dependencies on components that should really be independent. However, we can add a resetPermissions(user) and resetAuthorizations(user) to their respective components, so that at least authenticator plugins have the ability to reset these things when users are deleted if they want to.
          Hide
          John Vines added a comment -

          I implemented the three components with a validation check to make sure all of the components could play nice with eachother. The ZK ones are well tested and function standalone, so there was no issue there. It's really up to the developer of the plugin to determine if it doesn't work well, and their plugin should identify that in the implementation.

          The authenticator should have no direct interaction with any of the other components. The SecurityOperations dictates how Accumulo behaves. Once a user is authenticated, they are authenticated and the other interfaces just deal with answering questions about a principal. Period. And there already are methods for resetting user's permissions and authorizations. Look at Authorizor.dropUser(String) and PermissionHandler.cleanUser(String) [however, these should probably have the same nomenclature, now that I'm looking at them both]. All three methods are called in SecurityOperation in a consistent order. I feel strongly that these should remain 3 distinct components, or else any user who wants to harness an existing permission handler, lets say, needs to rewrite the whole class because they want to use a custom ldap system for authorization, etc. etc. Modularity here is the critical feature here, and merging to a single interface would work against it.

          Show
          John Vines added a comment - I implemented the three components with a validation check to make sure all of the components could play nice with eachother. The ZK ones are well tested and function standalone, so there was no issue there. It's really up to the developer of the plugin to determine if it doesn't work well, and their plugin should identify that in the implementation. The authenticator should have no direct interaction with any of the other components. The SecurityOperations dictates how Accumulo behaves. Once a user is authenticated, they are authenticated and the other interfaces just deal with answering questions about a principal. Period. And there already are methods for resetting user's permissions and authorizations. Look at Authorizor.dropUser(String) and PermissionHandler.cleanUser(String) [however, these should probably have the same nomenclature, now that I'm looking at them both] . All three methods are called in SecurityOperation in a consistent order. I feel strongly that these should remain 3 distinct components, or else any user who wants to harness an existing permission handler, lets say, needs to rewrite the whole class because they want to use a custom ldap system for authorization, etc. etc. Modularity here is the critical feature here, and merging to a single interface would work against it.
          Hide
          Christopher Tubbs added a comment -

          John Vines:
          I referenced the validation check above. The reason I'm not a fan of that way of doing things is that without knowing anything about those other components, a developer of one has to enumerate all the possible implementations of the other components that it knows are compatible. This means that a developer would have to re-release new versions of his component every time other, compatible components of the other types are created/released, or make it configurable in their code, or most likely, just always return true. Re-releasing is not feasible, and it creates a configuration management nightmare for system admins, and it makes them less independent, and less modular. Configuration is a lateral move, and always returning true is something we should probably just do anyways by eliminating this check and deferring to system admins/configuration management people to ensure they choose components that are compatible.

          I agree the components shouldn't directly interact, and I also like the centralized "SecurityOperation" on the server side that brings them together. All I've suggested is that this "SecurityOperation" be configurable, instead of the 3 components... though I'd strongly support an implementation of a pluggable "SecurityOperation" or "UserSecurityPlugin" (as I'd probably call it), that is comprised of 3 distinct, modular components. (Example: "configuration.getUserSecurityPlugin().getAuthenticator();" vs. "configuration.getAuthenticator()") In this way, if there are any interactions necessary, they occur in a coherent way, within the configured SecurityOperation (or equivalent).

          The short answer is that one interface does not work against modularity, especially if that one interface is a factory for the 3 modular components. You don't necessarily need to "rewrite the whole class", either. In the typical case, a rewrite is trivial anyway... just change the return type in a factory.

          The alternative (and I think this is preferable...) is to simply assume compatibility, and by convention, if one implements user-management features in their Authenticator, then give the Authenticator access to call cleanUser/dropUser as appropriate.

          In any case, I just wanted to document the issue of interoperability... I'm not necessarily suggesting we change it at this point (it's kind of too late for 1.5.0, anyway). My focus on this ticket is about dealing with the "local user" concept above the comment which you replied to.

          Show
          Christopher Tubbs added a comment - John Vines : I referenced the validation check above. The reason I'm not a fan of that way of doing things is that without knowing anything about those other components, a developer of one has to enumerate all the possible implementations of the other components that it knows are compatible. This means that a developer would have to re-release new versions of his component every time other, compatible components of the other types are created/released, or make it configurable in their code, or most likely, just always return true. Re-releasing is not feasible, and it creates a configuration management nightmare for system admins, and it makes them less independent, and less modular. Configuration is a lateral move, and always returning true is something we should probably just do anyways by eliminating this check and deferring to system admins/configuration management people to ensure they choose components that are compatible. I agree the components shouldn't directly interact, and I also like the centralized "SecurityOperation" on the server side that brings them together. All I've suggested is that this "SecurityOperation" be configurable, instead of the 3 components... though I'd strongly support an implementation of a pluggable "SecurityOperation" or "UserSecurityPlugin" (as I'd probably call it), that is comprised of 3 distinct, modular components. (Example: "configuration.getUserSecurityPlugin().getAuthenticator();" vs. "configuration.getAuthenticator()") In this way, if there are any interactions necessary, they occur in a coherent way, within the configured SecurityOperation (or equivalent). The short answer is that one interface does not work against modularity, especially if that one interface is a factory for the 3 modular components. You don't necessarily need to "rewrite the whole class", either. In the typical case, a rewrite is trivial anyway... just change the return type in a factory. The alternative (and I think this is preferable...) is to simply assume compatibility, and by convention, if one implements user-management features in their Authenticator, then give the Authenticator access to call cleanUser/dropUser as appropriate. In any case, I just wanted to document the issue of interoperability... I'm not necessarily suggesting we change it at this point (it's kind of too late for 1.5.0, anyway). My focus on this ticket is about dealing with the "local user" concept above the comment which you replied to.
          Hide
          David Medinets added a comment -

          I should have referenced Tomcat a long time ago in this discussion of user management, but I just recently thought of it. I'd probably way too late to consider it. My understanding of Tomcat security is rudimentary. By default, there is a tomcat-users.xml file:

          <tomcat-users>
          <user name="tomcat" password="tomcat" roles="tomcat" />
          <user name="role1" password="tomcat" roles="role1" />
          <user name="both" password="tomcat" roles="tomcat,role1" />
          </tomcat-users>

          People can manually add users and need to manually add an admin role and user otherwise the management web application is disabled.

          For more flexibility, Tomcat can be configured to read users from a database, from LDAP, and probably a lot more. Since I don't know much more, I'll stop with that brief synopsis.

          Show
          David Medinets added a comment - I should have referenced Tomcat a long time ago in this discussion of user management, but I just recently thought of it. I'd probably way too late to consider it. My understanding of Tomcat security is rudimentary. By default, there is a tomcat-users.xml file: <tomcat-users> <user name="tomcat" password="tomcat" roles="tomcat" /> <user name="role1" password="tomcat" roles="role1" /> <user name="both" password="tomcat" roles="tomcat,role1" /> </tomcat-users> People can manually add users and need to manually add an admin role and user otherwise the management web application is disabled. For more flexibility, Tomcat can be configured to read users from a database, from LDAP, and probably a lot more. Since I don't know much more, I'll stop with that brief synopsis.
          Hide
          Christopher Tubbs added a comment -

          Oh, I see. That might be a useful Authenticator implementation, because it's easy to use. However, it's not very secure (it'd probably have to be stored in HDFS or some other shared location), and I wouldn't want to provide an implementation I wouldn't recommend.

          However, I would be interested in looking at how they do authentication in their code (I think they use JAAS LoginContext, with a PasswordCallback that reads this file), because that might be useful for us to adopt in the future, on the server side. However, it doesn't resolve the issues with the client side, because even LoginContext has the issue of how to get the credentials to the CallbackHandler's respective Callbacks on the server side.

          With the generic token handling, we're essentially supporting single sign-on (SSO)... however the SSO tokens are authenticated, we need to pass them to the server.

          Show
          Christopher Tubbs added a comment - Oh, I see. That might be a useful Authenticator implementation, because it's easy to use. However, it's not very secure (it'd probably have to be stored in HDFS or some other shared location), and I wouldn't want to provide an implementation I wouldn't recommend. However, I would be interested in looking at how they do authentication in their code (I think they use JAAS LoginContext, with a PasswordCallback that reads this file), because that might be useful for us to adopt in the future, on the server side. However, it doesn't resolve the issues with the client side, because even LoginContext has the issue of how to get the credentials to the CallbackHandler's respective Callbacks on the server side. With the generic token handling, we're essentially supporting single sign-on (SSO)... however the SSO tokens are authenticated, we need to pass them to the server.
          Hide
          Hudson added a comment -

          Integrated in Accumulo-1.5 #15 (See https://builds.apache.org/job/Accumulo-1.5/15/)
          ACCUMULO-966 - Switching proxy to use a properties map
          ACCUMULO-1024 - Switched proxy to specify Local user operations (Revision 1452946)

          Result = SUCCESS
          vines :
          Files :

          • /accumulo/branches/1.5/core/src/main/java/org/apache/accumulo/core/security/CredentialHelper.java
          • /accumulo/branches/1.5/proxy/src/main/java/org/apache/accumulo/proxy/ProxyServer.java
          • /accumulo/branches/1.5/proxy/src/main/java/org/apache/accumulo/proxy/TestProxyClient.java
          • /accumulo/branches/1.5/proxy/src/main/java/org/apache/accumulo/proxy/thrift/AccumuloProxy.java
          • /accumulo/branches/1.5/proxy/src/main/java/org/apache/accumulo/proxy/thrift/UserPass.java
          • /accumulo/branches/1.5/proxy/src/main/thrift/proxy.thrift
          • /accumulo/branches/1.5/proxy/src/test/java/org/apache/accumulo/proxy/SimpleTest.java
          • /accumulo/branches/1.5/proxy/src/test/java/org/apache/accumulo/proxy/TestProxyInstanceOperations.java
          • /accumulo/branches/1.5/proxy/src/test/java/org/apache/accumulo/proxy/TestProxyReadWrite.java
          • /accumulo/branches/1.5/proxy/src/test/java/org/apache/accumulo/proxy/TestProxySecurityOperations.java
          • /accumulo/branches/1.5/proxy/src/test/java/org/apache/accumulo/proxy/TestProxyTableOperations.java
          Show
          Hudson added a comment - Integrated in Accumulo-1.5 #15 (See https://builds.apache.org/job/Accumulo-1.5/15/ ) ACCUMULO-966 - Switching proxy to use a properties map ACCUMULO-1024 - Switched proxy to specify Local user operations (Revision 1452946) Result = SUCCESS vines : Files : /accumulo/branches/1.5/core/src/main/java/org/apache/accumulo/core/security/CredentialHelper.java /accumulo/branches/1.5/proxy/src/main/java/org/apache/accumulo/proxy/ProxyServer.java /accumulo/branches/1.5/proxy/src/main/java/org/apache/accumulo/proxy/TestProxyClient.java /accumulo/branches/1.5/proxy/src/main/java/org/apache/accumulo/proxy/thrift/AccumuloProxy.java /accumulo/branches/1.5/proxy/src/main/java/org/apache/accumulo/proxy/thrift/UserPass.java /accumulo/branches/1.5/proxy/src/main/thrift/proxy.thrift /accumulo/branches/1.5/proxy/src/test/java/org/apache/accumulo/proxy/SimpleTest.java /accumulo/branches/1.5/proxy/src/test/java/org/apache/accumulo/proxy/TestProxyInstanceOperations.java /accumulo/branches/1.5/proxy/src/test/java/org/apache/accumulo/proxy/TestProxyReadWrite.java /accumulo/branches/1.5/proxy/src/test/java/org/apache/accumulo/proxy/TestProxySecurityOperations.java /accumulo/branches/1.5/proxy/src/test/java/org/apache/accumulo/proxy/TestProxyTableOperations.java
          Hide
          Hudson added a comment -

          Integrated in Accumulo-Trunk #759 (See https://builds.apache.org/job/Accumulo-Trunk/759/)
          ACCUMULO-966 - Switching proxy to use a properties map
          ACCUMULO-1024 - Switched proxy to specify Local user operations (Revision 1452947)

          Result = SUCCESS
          vines :
          Files :

          • /accumulo/trunk
          • /accumulo/trunk/core
          • /accumulo/trunk/core/src/main/java/org/apache/accumulo/core/security/CredentialHelper.java
          • /accumulo/trunk/proxy/src/main/java/org/apache/accumulo/proxy/ProxyServer.java
          • /accumulo/trunk/proxy/src/main/java/org/apache/accumulo/proxy/TestProxyClient.java
          • /accumulo/trunk/proxy/src/main/java/org/apache/accumulo/proxy/thrift/AccumuloProxy.java
          • /accumulo/trunk/proxy/src/main/java/org/apache/accumulo/proxy/thrift/UserPass.java
          • /accumulo/trunk/proxy/src/main/thrift/proxy.thrift
          • /accumulo/trunk/proxy/src/test/java/org/apache/accumulo/proxy/SimpleTest.java
          • /accumulo/trunk/proxy/src/test/java/org/apache/accumulo/proxy/TestProxyInstanceOperations.java
          • /accumulo/trunk/proxy/src/test/java/org/apache/accumulo/proxy/TestProxyReadWrite.java
          • /accumulo/trunk/proxy/src/test/java/org/apache/accumulo/proxy/TestProxySecurityOperations.java
          • /accumulo/trunk/proxy/src/test/java/org/apache/accumulo/proxy/TestProxyTableOperations.java
          Show
          Hudson added a comment - Integrated in Accumulo-Trunk #759 (See https://builds.apache.org/job/Accumulo-Trunk/759/ ) ACCUMULO-966 - Switching proxy to use a properties map ACCUMULO-1024 - Switched proxy to specify Local user operations (Revision 1452947) Result = SUCCESS vines : Files : /accumulo/trunk /accumulo/trunk/core /accumulo/trunk/core/src/main/java/org/apache/accumulo/core/security/CredentialHelper.java /accumulo/trunk/proxy/src/main/java/org/apache/accumulo/proxy/ProxyServer.java /accumulo/trunk/proxy/src/main/java/org/apache/accumulo/proxy/TestProxyClient.java /accumulo/trunk/proxy/src/main/java/org/apache/accumulo/proxy/thrift/AccumuloProxy.java /accumulo/trunk/proxy/src/main/java/org/apache/accumulo/proxy/thrift/UserPass.java /accumulo/trunk/proxy/src/main/thrift/proxy.thrift /accumulo/trunk/proxy/src/test/java/org/apache/accumulo/proxy/SimpleTest.java /accumulo/trunk/proxy/src/test/java/org/apache/accumulo/proxy/TestProxyInstanceOperations.java /accumulo/trunk/proxy/src/test/java/org/apache/accumulo/proxy/TestProxyReadWrite.java /accumulo/trunk/proxy/src/test/java/org/apache/accumulo/proxy/TestProxySecurityOperations.java /accumulo/trunk/proxy/src/test/java/org/apache/accumulo/proxy/TestProxyTableOperations.java
          Hide
          Hudson added a comment -

          Integrated in Accumulo-Trunk-Hadoop-2.0 #118 (See https://builds.apache.org/job/Accumulo-Trunk-Hadoop-2.0/118/)
          ACCUMULO-966 - Switching proxy to use a properties map
          ACCUMULO-1024 - Switched proxy to specify Local user operations (Revision 1452947)

          Result = SUCCESS
          vines :
          Files :

          • /accumulo/trunk
          • /accumulo/trunk/core
          • /accumulo/trunk/core/src/main/java/org/apache/accumulo/core/security/CredentialHelper.java
          • /accumulo/trunk/proxy/src/main/java/org/apache/accumulo/proxy/ProxyServer.java
          • /accumulo/trunk/proxy/src/main/java/org/apache/accumulo/proxy/TestProxyClient.java
          • /accumulo/trunk/proxy/src/main/java/org/apache/accumulo/proxy/thrift/AccumuloProxy.java
          • /accumulo/trunk/proxy/src/main/java/org/apache/accumulo/proxy/thrift/UserPass.java
          • /accumulo/trunk/proxy/src/main/thrift/proxy.thrift
          • /accumulo/trunk/proxy/src/test/java/org/apache/accumulo/proxy/SimpleTest.java
          • /accumulo/trunk/proxy/src/test/java/org/apache/accumulo/proxy/TestProxyInstanceOperations.java
          • /accumulo/trunk/proxy/src/test/java/org/apache/accumulo/proxy/TestProxyReadWrite.java
          • /accumulo/trunk/proxy/src/test/java/org/apache/accumulo/proxy/TestProxySecurityOperations.java
          • /accumulo/trunk/proxy/src/test/java/org/apache/accumulo/proxy/TestProxyTableOperations.java
          Show
          Hudson added a comment - Integrated in Accumulo-Trunk-Hadoop-2.0 #118 (See https://builds.apache.org/job/Accumulo-Trunk-Hadoop-2.0/118/ ) ACCUMULO-966 - Switching proxy to use a properties map ACCUMULO-1024 - Switched proxy to specify Local user operations (Revision 1452947) Result = SUCCESS vines : Files : /accumulo/trunk /accumulo/trunk/core /accumulo/trunk/core/src/main/java/org/apache/accumulo/core/security/CredentialHelper.java /accumulo/trunk/proxy/src/main/java/org/apache/accumulo/proxy/ProxyServer.java /accumulo/trunk/proxy/src/main/java/org/apache/accumulo/proxy/TestProxyClient.java /accumulo/trunk/proxy/src/main/java/org/apache/accumulo/proxy/thrift/AccumuloProxy.java /accumulo/trunk/proxy/src/main/java/org/apache/accumulo/proxy/thrift/UserPass.java /accumulo/trunk/proxy/src/main/thrift/proxy.thrift /accumulo/trunk/proxy/src/test/java/org/apache/accumulo/proxy/SimpleTest.java /accumulo/trunk/proxy/src/test/java/org/apache/accumulo/proxy/TestProxyInstanceOperations.java /accumulo/trunk/proxy/src/test/java/org/apache/accumulo/proxy/TestProxyReadWrite.java /accumulo/trunk/proxy/src/test/java/org/apache/accumulo/proxy/TestProxySecurityOperations.java /accumulo/trunk/proxy/src/test/java/org/apache/accumulo/proxy/TestProxyTableOperations.java
          Hide
          Hudson added a comment -

          Integrated in Accumulo-1.5-Hadoop-2.0 #15 (See https://builds.apache.org/job/Accumulo-1.5-Hadoop-2.0/15/)
          ACCUMULO-966 - Switching proxy to use a properties map
          ACCUMULO-1024 - Switched proxy to specify Local user operations (Revision 1452946)

          Result = SUCCESS
          vines :
          Files :

          • /accumulo/branches/1.5/core/src/main/java/org/apache/accumulo/core/security/CredentialHelper.java
          • /accumulo/branches/1.5/proxy/src/main/java/org/apache/accumulo/proxy/ProxyServer.java
          • /accumulo/branches/1.5/proxy/src/main/java/org/apache/accumulo/proxy/TestProxyClient.java
          • /accumulo/branches/1.5/proxy/src/main/java/org/apache/accumulo/proxy/thrift/AccumuloProxy.java
          • /accumulo/branches/1.5/proxy/src/main/java/org/apache/accumulo/proxy/thrift/UserPass.java
          • /accumulo/branches/1.5/proxy/src/main/thrift/proxy.thrift
          • /accumulo/branches/1.5/proxy/src/test/java/org/apache/accumulo/proxy/SimpleTest.java
          • /accumulo/branches/1.5/proxy/src/test/java/org/apache/accumulo/proxy/TestProxyInstanceOperations.java
          • /accumulo/branches/1.5/proxy/src/test/java/org/apache/accumulo/proxy/TestProxyReadWrite.java
          • /accumulo/branches/1.5/proxy/src/test/java/org/apache/accumulo/proxy/TestProxySecurityOperations.java
          • /accumulo/branches/1.5/proxy/src/test/java/org/apache/accumulo/proxy/TestProxyTableOperations.java
          Show
          Hudson added a comment - Integrated in Accumulo-1.5-Hadoop-2.0 #15 (See https://builds.apache.org/job/Accumulo-1.5-Hadoop-2.0/15/ ) ACCUMULO-966 - Switching proxy to use a properties map ACCUMULO-1024 - Switched proxy to specify Local user operations (Revision 1452946) Result = SUCCESS vines : Files : /accumulo/branches/1.5/core/src/main/java/org/apache/accumulo/core/security/CredentialHelper.java /accumulo/branches/1.5/proxy/src/main/java/org/apache/accumulo/proxy/ProxyServer.java /accumulo/branches/1.5/proxy/src/main/java/org/apache/accumulo/proxy/TestProxyClient.java /accumulo/branches/1.5/proxy/src/main/java/org/apache/accumulo/proxy/thrift/AccumuloProxy.java /accumulo/branches/1.5/proxy/src/main/java/org/apache/accumulo/proxy/thrift/UserPass.java /accumulo/branches/1.5/proxy/src/main/thrift/proxy.thrift /accumulo/branches/1.5/proxy/src/test/java/org/apache/accumulo/proxy/SimpleTest.java /accumulo/branches/1.5/proxy/src/test/java/org/apache/accumulo/proxy/TestProxyInstanceOperations.java /accumulo/branches/1.5/proxy/src/test/java/org/apache/accumulo/proxy/TestProxyReadWrite.java /accumulo/branches/1.5/proxy/src/test/java/org/apache/accumulo/proxy/TestProxySecurityOperations.java /accumulo/branches/1.5/proxy/src/test/java/org/apache/accumulo/proxy/TestProxyTableOperations.java
          Hide
          John Vines added a comment -

          What is your status on this ticket? I'm weary to do any 259 documentation until the dust clears. I would work on this, but you've had it marked in progress for a while. If you can give an update, I have some cycles to wrap on this.

          Show
          John Vines added a comment - What is your status on this ticket? I'm weary to do any 259 documentation until the dust clears. I would work on this, but you've had it marked in progress for a while. If you can give an update, I have some cycles to wrap on this.
          Hide
          Christopher Tubbs added a comment -

          I think this is all I'm going to do for 1.5. I think this should be revisited for 1.6, though, because I'm still a bit unsatisfied with the fact that the currently implemented design (from this ticket, and in related ACCUMULO-259 tickets) weren't given enough review, before being implemented at the last minute.

          Show
          Christopher Tubbs added a comment - I think this is all I'm going to do for 1.5. I think this should be revisited for 1.6, though, because I'm still a bit unsatisfied with the fact that the currently implemented design (from this ticket, and in related ACCUMULO-259 tickets) weren't given enough review, before being implemented at the last minute.
          Hide
          Christopher Tubbs added a comment -

          If there's more to do here, it'll be done under ACCUMULO-1300.

          Show
          Christopher Tubbs added a comment - If there's more to do here, it'll be done under ACCUMULO-1300 .

            People

            • Assignee:
              Christopher Tubbs
              Reporter:
              Christopher Tubbs
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development