deploy service and roles

[Paul Pound]

We've been using the duracloud rest api to integrate with islandora.
We can get content and properties and list services etc. but when
trying to deploy the bitintegrity service we are getting a 403
forbidden. We are trying this as a limited user (just a normal User
not Administrator or owner).

I've looked at this page https://wiki.duraspace.org/display/DURACLOUDDOC/DuraCloud+Security
and it looks like a user should be able to deploy a service. Is that
correct?

I can't see a way to deploy a service when logged in to duracloud as a
non admin user either so I maybe missing something?

Thanks,
Paul

[Bill Branan]

Hi Paul,

To start a service, you will need to make the call with a user that has either the ADMIN or OWNER role. Part of the goal for the 2.0.0 release was simplifying the interaction with DuraCloud for those with role USER, and that resulted in a variety of changes, including the automation of several services, as well as the adjusting of user privileges. Unfortunately, it looks like we missed updating that bit of documentation in the process. There is a bit more work left to clean up the security settings (noted here: https://jira.duraspace.org/browse/DURACLOUD-668), and I've noted the need to update the documentation to bring it up to date with the code.

Sorry for the confusion. Let us know if you run into any other issues as you work on the integration.

Bill 

--
You received this message because you are subscribed to the Google Groups "DuraCloud Dev" group.
To post to this group, send email to duracl...@googlegroups.com.
To unsubscribe from this group, send email to duracloud-de...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/duracloud-dev?hl=en.

[Paul Pound]

Hi Bill,

Thanks for the quick response.

Yeah, it's a job and a half just keeping documentation up to date.  

What would work well for us would be users with the USER role being able to run services for spaces that they have read/write access on.  Or similarly it would work if we could limit an Adminstrator type user to a certain space/spaces.   We have many Drupal/Islandora instances pointed at one Fedora and in some cases the Fedora items each Islandora instance can access is limited.  We would like to limit what each Islandora instance can access in Duracloud as well (which we can do with different users and spaces) but also allow their Islandora instance to deploy services (really only the integrity related ones) from Duracloud for their space.  

I'm guessing though that for now we will need different Duracloud instances for this type of behaviour?

I also think we can mimic some of this behaviour with someone managing the services and running/scheduling the services on behalf of each site but if each site could manage their own it would be better for our use case.  Some of my assumptions maybe incorrect (let me know if they are) as we are really just getting into the details.

Thanks again,

Paul

[Bill Branan]

Hi Paul,

What we found to be the case for DuraCloud is that our users really prefer for services like bit integrity to simply be managed for them. Everybody liked the idea of frequent bit integrity checking, but very few were interested in managing the details. That is what led us to the development of the Executor piece of the new-to-2.0.0 DuraBoss application. If you're not familiar with it, the Executor lets you manage certain services at a higher level. In particular, the services that the Executor deals with at the moment are bit integrity and media streaming, but the plan is to include many of the other services as well. For bit integrity, you can make one call to the Executor specifying when it should start the next round of bit integrity checks and how often after that it should repeat the cycle. The Executor will then handle running the Bit Integrity Service for you over all of the spaces in a DuraCloud account. When starting a DuraCloud instance, we now configure the Executor to run bit integrity checks starting on a Saturday morning about once a month. The "Last Health Check" row in the space details area of the UI shows when the last successful bit integrity check was run over a given space.

Clearly you weren't asking about the Executor piece, but it does do rather a lot of work for you. You now get a bit integrity check over each space every 4 weeks without having to do anything. If you'd like to change the schedule of the bit integrity runs, you can do so by making calls as noted here:  https://wiki.duraspace.org/display/DURACLOUDDOC/DuraCloud+REST+API#DuraCloudRESTAPI-GetSupportedExecutorActions.

If you'd like to continue running the Bit Integrity Service on your own, which you're welcome to do, you will need to do so with an ADMIN or OWNER role user, as there's not currently a way for those with USER role to kick off services. One of the reasons for that is that we currently only allow a single copy of any service to be running at a time. So even if we did open up access to allow those with USER role to run services, you'd need to put limits in place so that not more than one user would try to run the service while it is running for another user. We also decided that in the multi-tenant case, like you're describing, those with USER role might see information in the service configuration that they should not see otherwise (like a space name they don't have access to, and the number of items in that space). Keeping the running of services as an administrative task seemed like the best solution to these concerns.

I'll be interested to know what direction you decide to go on this. Feel free to ask other questions as they come up.

Bill

[Paul Pound]

Thanks for the info Bill.  The executor maybe all we need.  

One of the reasons I was looking at the services is that it looked like we could run it as a non privileged user (i was incorrect in that assumption) and it looked to me like the executor stuff required a privileged user.  But i can see the health check report as a non privileged user in the Duracloud gui so can i get to it using the api?  If we can access that as just a USER I think that would satisfy our needs for now.  

I'm looking at this page again https://wiki.duraspace.org/display/DURACLOUDDOC/DuraCloud+Security and it looks like the executor and reports require admin privileges.  I know this may not be accurate.  All the non privileged user would need is access to the latest report via the api, they wouldn't need to schedule it or run it.  

Below is a quick overview of what we have so far and what we would like to do:

We create a space in Duracloud and create a USER with read and write access to that space (DGI or UPEI would set this up).  We then create a store in Cloudsync with that user info and then provide that Cloudsync store uri to Islandora, an admin would update Islandora config with the uri.  Using the Cloudsync api we can create tasks and sets based on fedora objects and collections from within Islandora.  We can also run the tasks from within Islandora.  The user information from that Cloudsync store can also be used to connect to Duracloud to compare checksums and hopefully get the executor health status reports.  

I agree with the users wanting stuff managed for them, we are trying to make it as simple as possible for islandora users, Ideally they would never have to actually login to Cloudsync or Duracloud but still get all the benefits by configuring Islandora to use these services.

Thanks again for your help,

Paul

[Bill Branan]

Hi Paul,

Your plan for integration with DuraCloud via CloudSync sounds like a good one. Regarding getting access to reports, there are a few ways that could be done. The bit integrity reports are stored in the x-service-out space, this is where service reports always go, regardless of whether they are managed by the executor or the service is run independently. That space is not configured by default to be readable by anyone but administrators. To show the reports to the user in the DuraCloud UI we actually use another set of access credentials rather than those of the logged in user.

A few possible ways for you to provide users with access to reports:

1. Set access controls in DuraCloud to open up access to the x-service-out space. This would give all users access to all reports for everyone, which may not be desirable, but it would be simple.

2. Set up a CloudSync store with acces to x-service-out, and have it pull the reports into Fedora. You'd then be able to use Fedora access controls to set which users can see which reports.

3. Set up a batch job that can use the DuraCloud API (with admin credentials) to copy reports from x-service-out into a space which the user does have access to see them. You would then be able to use the CloudSync integration to retrieve the reports for the user.

As a note, the storage reports (which provide the data for the History charts) are stored in the x-duracloud-admin space (they are created by the Reporter portion of DuraBoss, not a service). You could use the same strategy as for bit integrity reports if you want users to be able to see the storage reports.

Hopefully this helps.

Bill

[Paul Pound]

Hi Bill,

Thanks again for your help.  I think they could all be viable options, especially #2 and #3.  

Paul