user accounts in DuraCloud 3.1.1

[Alan Darnell]

We've got DuraCloud running locally and can log in to the duradmin interface using credentials we added to init.properties but we can't see in the admin tool any place for adding new users and assigning them to spaces. I can see the user we created listed under the Administration tab, but there are no controls to create new users.    I notice too that on the DuraCloud site itself there is a create profile link on the login page that seems to be missing in the local installation.  Makes me think that we must be missing something in our installation or in our init.properties file.  Any pointers would be appreciated.

[Bill Branan]

Hi Alan,

There is actually another application which currently provides the account and user administration pieces of the DuraCloud service. We call this application the DuraCloud Management Console. We do have the goal of moving the user administration section over to be a part of the primary DuraCloud baseline, but that likely won't happen for several months, due to other commitments. The Management Console isn't technically open source, but if you have a need for it, let me know and we can discuss what it does more in depth. Of course, there is also the option to develop your own code/scripts which add users via calls to the REST API. I know that some others have done this because they didn't need all of the features/complexity that was involved with the Management Console.

Bill

On Thu, Aug 7, 2014 at 4:09 PM, Alan Darnell <alan.d...@gmail.com> wrote:

We've got DuraCloud running locally and can log in to the duradmin interface using credentials we added to init.properties but we can't see in the admin tool any place for adding new users and assigning them to spaces. I can see the user we created listed under the Administration tab, but there are no controls to create new users.    I notice too that on the DuraCloud site itself there is a create profile link on the login page that seems to be missing in the local installation.  Makes me think that we must be missing something in our installation or in our init.properties file.  Any pointers would be appreciated.

--
You received this message because you are subscribed to the Google Groups "DuraCloud Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to duracloud-de...@googlegroups.com.
To post to this group, send email to duracl...@googlegroups.com.
Visit this group at http://groups.google.com/group/duracloud-dev.
For more options, visit https://groups.google.com/d/optout.

[Alan Darnell]

Good to know we didn't mess up with the install.  We will look at the REST API to see what it provides.

Our approach to accounts might be a little different from yours.  We will be setting up an OpenStack account for each library in our consortium -- 21 in total.  Each account would have access to its own set of containers as created and managed by the local library admin.  He/she would then be able to assign access to specific containers to particular users at each institution.  The idea would be to allow users to self register and then request access from the local admin to specific containers.  We were thinking that DuraCloud might be a tool to abstract the idea of a container, and to allow users to choose containers with certain service level characteristics (redundancy, retrieval speed) as provided by our OpenStack cluster or other commercial and non-commercial storage providers.  

In any case, thanks for your work with this -- it's good to have all this great code to build on.

Alan

[Bill Branan]

That's not too far off from what we do. Each DuraCloud account is associated with its own S3 account (and Rackspace, SDSC, or Glacier account as needed). DuraCloud then sits on top of that set of accounts. Users self register using the Mangement Console, then are assigned to an account via an administrator (also in the Management Console). Admins are then able to assign permissions to give users and/or groups read or write access to spaces (we use "space" as a generic term for OpenStack "containers", S3 "buckets", etc).

We don't currently provide a way for users to request permission for specific spaces (containers). We only allow users to see the spaces in the list which the have permission to view, so you would need to provide a way to give users that full listing if you want them to be able to choose from the full list of spaces. Again, this wouldn't be hard to do via the REST API, as you could use an administrator account to request the spaces listing. I should note that there is also a Java client (called storeclient in the codebase) which provides full access to the API through Java. We do have a notion of "space properties" which can be set on any space and displayed via the UI. This is a bit restricted (not available through the REST API, but could easily be set via a StorageProvider implementation) because these properties are very limited in S3, but that is not an issue with OpenStack. That could allow you to present the different service level characteristics to users for selection.

Bill