Dear Nirvanix Team:

 I was |-| close to going with Amazon's S3 service when I decided to (after 6 months of preparing my software) do one last check for a competitor.  I'm SOOOO glad I ran across your site!  I've signed up, obviously, and am ready to begin my journey with you.

 However, one snafu I ran into is this...

 I create a Master Account and put in my billing information.  Now, I have a develop who I need to give access to the account to so he can create sub accounts, delete them, review reports, etc.  However, in order for him to do this he must have my Master Account username and password.  This gives him full access to all of my billing information (at least to change) and even lock me out of my own account if changed the password!?

 Is there any plans to allow us to create sub-management accounts whereas my employees can do general work but not have access to my naughty bits?

 Keep up the great work!

- Joshua

Glad to have you on board, I hope you like the API and service so far.

DatSure:

Is there any plans to allow us to create sub-management accounts whereas my employees can do general work but not have access to my naughty bits?

Having the ability to define roles is something we have discussed but haven't started developing.  For now you will need to write your own security around the management of your accounts and master account.  I definitely understand the conundrum since the developer will have all of the keys to the castle. 

One thing you could do is use one of the sample applications to create the child accounts yourself and provide child accounts to the developer to work with.  This is quite a bit more work, but this will assure you have complete control of your account.  Some simple desktop applications for account management can be found in the downloads section in c# that will let you add child accounts, delete them, set the limits, etc.

For the ability to review the reports on usage there are API calls in the accounting namespace to retrieve usage for a child account.  This could be used instead of the Management portal (nmp.nirvanix.com) to review usage on children.  That assumes the developer has the ability to log in to each child they would need usage for.

I hope this helps a bit, I'm not sure if this can help since I'm guessing a bit on your implementation but feel free to ask any specific questions and we will be happy to help you get setup.

Regards,
    Barry R.

Barry:

 Thank you for the additional informations and suggestions.  I trust my programmer at this point so we'll work something out as a workaround.  However, I think this could become a larger issue with more and more users of your service and I would like to nominate it as a top priority to resovle this.

 Thanks!

 - Joshua

+1 - I am also very concerned giving master account details to my development team... very-not-cool.

easiest fix I can think of (not sure if this would work) is the option to de-couple the account password from the nmp.nirvanix.com password. On account creation you could set the nmp_password in your db to the same value as the 'account'/application password, so that they would remain the same for most folks... then provide a checkbox at https://nmp.nirvanix.com/changePassword.aspx so that people in our situation could specify that they ONLY want to change the NMP password for team-security-reasons. I can't see why a development team would need to log into the management portal.

 Yes, this has been a concern of ours for some time.  There are secondary concerns with this however when you consider the person with the master account can modify any file / folder / child account on the system even if they only have access to the web services.  I think the best solution would be an account that has master privileges to a single application and no way to log in to NMP.  This would be ideal since security would be per application and still allow child account creation / deletion and all of the other tasks.  We have been discussing this for some time but your request will raise its priority as well.

Regards,
     Barry R.