Mailing-List: contact issues-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Date: Wed, 11 May 2016 09:43:13 +0000 (UTC)
From: "ASF subversion and git services (JIRA)" <jira@apache.org>
To: cloudstack-issues@incubator.apache.org
Message-ID: <JIRA.12837926.1434394107000.163948.1462959793376@Atlassian.JIRA>
In-Reply-To: <JIRA.12837926.1434394107000@Atlassian.JIRA>
References: <JIRA.12837926.1434394107000@Atlassian.JIRA> <JIRA.12837926.1434394107609@arcas>
Subject: [jira] [Commented] (CLOUDSTACK-8562) User Definable Roles
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 11 May 2016 09:43:15 -0000


    [ https://issues.apache.org/jira/browse/CLOUDSTACK-8562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15279861#comment-15279861 ] 

ASF subversion and git services commented on CLOUDSTACK-8562:
-------------------------------------------------------------

Commit 4347776ac6ef9ae86fb016862f4a6b2376f8319a in cloudstack's branch refs/heads/4.9-bountycastle-daan from [~rohit.yadav@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4347776 ]

CLOUDSTACK-8562: DB-Backed Dynamic Role Based API Access Checker

This feature allows root administrators to define new roles and associate API
permissions to them.

A limited form of role-based access control for the CloudStack management server
API is provided through a properties file, commands.properties, embedded in the
WAR distribution. Therefore, customizing API permissions requires unpacking the
distribution and modifying this file consistently on all servers. The old system
also does not permit the specification of additional roles.

FS:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Dynamic+Role+Based+API+Access+Checker+for+CloudStack

DB-Backed Dynamic Role Based API Access Checker for CloudStack brings following
changes, features and use-cases:
- Moves the API access definitions from commands.properties to the mgmt server DB
- Allows defining custom roles (such as a read-only ROOT admin) beyond the
  current set of four (4) roles
- All roles will resolve to one of the four known roles types (Admin, Resource
  Admin, Domain Admin and User) which maintains this association by requiring
  all new defined roles to specify a role type.
- Allows changes to roles and API permissions per role at runtime including additions or
  removal of roles and/or modifications of permissions, without the need
  of restarting management server(s)

Upgrade/installation notes:
- The feature will be enabled by default for new installations, existing
  deployments will continue to use the older static role based api access checker
  with an option to enable this feature
- During fresh installation or upgrade, the upgrade paths will add four default
  roles based on the four default role types
- For ease of migration, at the time of upgrade commands.properties will be used
  to add existing set of permissions to the default roles. cloud.account
  will have a new role_id column which will be populated based on default roles
  as well

Dynamic-roles migration tool: scripts/util/migrate-dynamicroles.py
- Allows admins to migrate to the dynamic role based checker at a future date
- Performs a harder one-way migrate and update
- Migrates rules from existing commands.properties file into db and deprecates it
- Enables an internal hidden switch to enable dynamic role based checker feature

Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>


> User Definable Roles
> --------------------
>
>                 Key: CLOUDSTACK-8562
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8562
>             Project: CloudStack
>          Issue Type: New Feature
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Management Server
>            Reporter: Paul Angus
>            Assignee: Rohit Yadav
>
> Static command.properties moved to database and made user definable


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)