----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/47010/#review131999 -----------------------------------------------------------
Ship it! Ship It! - Sebastian Toader On May 5, 2016, 2:19 p.m., Robert Levas wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/47010/ > ----------------------------------------------------------- > > (Updated May 5, 2016, 2:19 p.m.) > > > Review request for Ambari, DIPAYAN BHOWMICK, Jonathan Hurley, Nate Cole, and > Sebastian Toader. > > > Bugs: AMBARI-16246 > https://issues.apache.org/jira/browse/AMBARI-16246 > > > Repository: ambari > > > Description > ------- > > To support assigning privileges to users based on their roles provide support > in the Ambari database to allow a `role` to be referenced as a `principal` > similar in the way a `user` and a `group` a referenced as a `principal`. > > A use-case to support the need for this is to assign access to a view to all > users with some specific role. Currently we can assign access to a view to a > specific user or group by assigning that user or group the `VIEW.USER` role > applied to the specific view. To assign access a view to users who have a > specific role, a `role` will need to behave like a `principal`. > > The following changes need to be made to the database: > > * Add `principal_id` column to the `adminpermission` table > * Create a `principaltype` record where the `principal_type_name` is '`ROLE`' > * Add records to the `adminprincpal` table to represent each role in > `adminpermission` > * Update `adminpermission.principal_id` to match the relevant records from > `adminprincipal` > > After this is complete, `adminprivilege` records can be created using roles > as principals. > > NOTE: special handling will need to be done in the authorization logic to > dereference the role associations with the authenticated user, similar in the > way this is done for groups. > > > Diffs > ----- > > > ambari-server/src/main/java/org/apache/ambari/server/orm/dao/PermissionDAO.java > 5d1a04a > > ambari-server/src/main/java/org/apache/ambari/server/orm/entities/PermissionEntity.java > 43fd71b > > ambari-server/src/main/java/org/apache/ambari/server/orm/entities/PrincipalEntity.java > 25d8d14 > > ambari-server/src/main/java/org/apache/ambari/server/orm/entities/PrincipalTypeEntity.java > b94f1ff > > ambari-server/src/main/java/org/apache/ambari/server/upgrade/AbstractUpgradeCatalog.java > 17f9fe1 > > ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog240.java > f85a4c7 > ambari-server/src/main/resources/Ambari-DDL-Derby-CREATE.sql f5336bc > ambari-server/src/main/resources/Ambari-DDL-MySQL-CREATE.sql fca3be3 > ambari-server/src/main/resources/Ambari-DDL-Oracle-CREATE.sql ce0bd84 > ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql 7fb8c31 > ambari-server/src/main/resources/Ambari-DDL-Postgres-EMBEDDED-CREATE.sql > 0f3a2c2 > ambari-server/src/main/resources/Ambari-DDL-SQLAnywhere-CREATE.sql b89389c > ambari-server/src/main/resources/Ambari-DDL-SQLServer-CREATE.sql 1107c4d > > ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog240Test.java > 7c85ba7 > > Diff: https://reviews.apache.org/r/47010/diff/ > > > Testing > ------- > > Manually tested newly created instance and upgrading from 2.2.1. Focused on > postgresql and mysql. > > # Local test results: > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD SUCCESS > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 1:16:03.148s > [INFO] Finished at: Wed May 04 18:43:11 EDT 2016 > [INFO] Final Memory: 60M/1768M > [INFO] > ------------------------------------------------------------------------ > > # Jenkins test results: PENDING > > > Thanks, > > Robert Levas > >