Return-Path: 
 <cloudstack-users-return-335-apmail-incubator-cloudstack-users-archive=incubator.apache.org@incubator.apache.org>
X-Original-To: apmail-incubator-cloudstack-users-archive@minotaur.apache.org
Delivered-To: apmail-incubator-cloudstack-users-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id D2E25C340
	for <apmail-incubator-cloudstack-users-archive@minotaur.apache.org>;
 Wed,  6 Jun 2012 08:29:16 +0000 (UTC)
Received: (qmail 83008 invoked by uid 500); 6 Jun 2012 08:29:16 -0000
Delivered-To: apmail-incubator-cloudstack-users-archive@incubator.apache.org
Received: (qmail 82709 invoked by uid 500); 6 Jun 2012 08:29:12 -0000
Mailing-List: contact cloudstack-users-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:cloudstack-users-help@incubator.apache.org>
List-Unsubscribe: <mailto:cloudstack-users-unsubscribe@incubator.apache.org>
List-Post: <mailto:cloudstack-users@incubator.apache.org>
List-Id: <cloudstack-users.incubator.apache.org>
Reply-To: cloudstack-users@incubator.apache.org
Delivered-To: mailing list cloudstack-users@incubator.apache.org
Received: (qmail 82669 invoked by uid 99); 6 Jun 2012 08:29:10 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Jun 2012 08:29:10 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=5.0
	tests=SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of Prasanna.Santhanam@citrix.com
 designates 203.166.19.134 as permitted sender)
Received: from [203.166.19.134] (HELO SMTP.CITRIX.COM.AU) (203.166.19.134)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Jun 2012 08:29:03 +0000
X-IronPort-AV: E=Sophos;i="4.75,723,1330905600";
   d="scan'208";a="11632632"
Received: from banpmailmx02.citrite.net ([10.103.128.74])
  by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/RC4-MD5;
 06 Jun 2012 08:28:40 +0000
Received: from citrix.com (10.146.0.130) by BANPMAILMX02.citrite.net
 (10.103.128.74) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012
 13:58:39 +0530
Date: Wed, 6 Jun 2012 13:58:38 +0530
From: Prasanna Santhanam <Prasanna.Santhanam@citrix.com>
To: "cloudstack-users@incubator.apache.org"
	<cloudstack-users@incubator.apache.org>
Subject: Re: registerUserKeys API
Message-ID: <20120606082838.GB13905@cloud.com>
Mail-Followup-To: "cloudstack-users@incubator.apache.org"
 <cloudstack-users@incubator.apache.org>
References: 
 <CAOYO+sYg7VnHBw039oBb86OyA0fe7u7ttBK2M91sVsTFoLiYkA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: 
 <CAOYO+sYg7VnHBw039oBb86OyA0fe7u7ttBK2M91sVsTFoLiYkA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)


> Several questions regarding the "registerUserKeys" API:
> 
> 1. Only the ROOT admin have access to it. In a public cloud, it does not
> make sense for the ROOT admin to create keys for every user in every
> domain. The responsibility should go to domain admins. Is there a plan to
> give domain admin access to the API?

I agree. Once an admin has created an account for a tenant he/she
should be able to alter the keys for his/her account. These keys are
necessarily resources belonging to a user and less to do with the
admin of the cloud/domain-admin of the domain. Perhaps we should make
the API user level.

> 2. The API simply takes user id as parameter. It does not take into account
> whether the user already has a key or not. User's key will be overwritten
> if he/she already has one. Should we change the API a little bit to take
> this into account?

Yes - again. I think we should'nt disturb keys that already exist.
Overwriting them without warning is going to break the integration the
user has put in to his client side code.

Also - it would be nicer to have the API accept the account name and
the name of the user in that account. 

registerUserKeys&account=<acct>&domainid=<dom>&user=<username>

> 3. You can actually generate key for the internal "system" user (with
> id=0). It might cause some issues if "system" is meant to be an internal
> user only. Is there a valid use case for system user to use its API key? If
> not, it should be blocked.
> 

Can't think of a use case. But since the listUser API is admin only
there's going to be no way for non-admin userse to see those keys. If
the above two enhancements do happen this should be blocked.


-- 
Prasanna.,