Re: [Handle-info] Distributed handle administrators

[Sean Reilly <sreilly@cnri.reston.va.us>]

On Sep 1, 2008, at 2:16 AM, Scott Yeadon wrote:

> Hi,
>
> We want to provide a handle service that may be used by various  
> applications and individual users to mint and update handles.  These  
> services will be simple HTTP services. For all handles minted a  
> system-level admin is assigned across all handles to support admin  
> functions performed by the handle service (housekeeping, etc). In  
> addition to this, the individuals (or applications) are also  
> required to be administrators of the handles they mint meaning each  
> handle record has at least two HS_ADMIN entries.
>
> Two simple scenarios these HTTP services might support are as follows:
>
> 1) a user wanting to acquire an identifier for a paper on his/her  
> website would log onto a user interface. This UI would authenticate  
> them against the system and if successful also determine whether  
> they have access to the handle service for minting identifiers.  
> Assuming the user has access to the minting service they are able to  
> get themselves an identifier and map it to the URL of the paper on  
> their site.
>
> In order to cope with updates to this handle, I assume the user  
> would need to also be assigned a handle in order that they are able  
> to (via UI or whatever) update the handle record if they need to.
>
> 2) A similar situation is the case where the mint/update services  
> are being utilised by an external application. For example an  
> repository application at an institution might make use of our  
> handle mint/update services using service calls within the software.  
> The application or the scope which it serves (dept, institution)  
> would be assigned a handle and the handle added to the list of  
> admins when the mint service was called.
>
> I am unsure of what information should be stored against the admin  
> handle records in these instances. The answer would appear to be  
> whatever is needed to satisfy the handle service the agent (person  
> or app) is allowed to undertake administration, be it a user id, a  
> role (for role-based access), a key (for cert-based access). Have  
> others implemented similar systems and have advice?
>
> Applications such as DSpace and Fedora appear to deal with this at  
> the application layer, i.e. their handle system is (tightly?)  
> coupled with the application meaning the application authentication  
> and authorisation process wraps handle minting/update operations  
> within some higher-level object operation (e.g. create object,  
> update object, modify object properties, etc). In our case the  
> identifier service is somewhat disembodied from the context in which  
> they are being created/updated which creates more complexity in the  
> logistics for authorisation and authentication.
>
> Any comments by those who have tackled this before would be welcome,  
> really just to ascertain that I'm not making things more complex  
> than they need to be.

Hi Scott,

We've had plenty of experience with similar setups.  Part of the issue  
has been that the handle protocol eliminates man-in-the-middle attacks  
which means that clients (whether individuals, organizations or  
applications) would need to send their actual authentication  
credentials (secret key or private key) to your service.  Applications  
such as DSpace address this by being very tightly integrated with  
their handle services.  In fact, DSpace handle servers are really just  
front-ends to the repository.  With DSpace there isn't any handle  
database, just the repository database in which some other process  
creates/modifies/deletes records.

I can think of two ways to approach this.  You might have already  
considered these, but here they are:
1) Use your own authentication/admin model for the web service and  
setup a handle service that is a resolution-only front-end for your  
database of handles.  A variation on this would be to have your web  
interface update a specialized database and then create a second  
"synchronizer" that pushed any changes to the database to a separate  
handle server (or vice versa).  The advantage to this model is that  
your administrative model (groups, individuals, permissions, etc) can  
be as flexible as you need.

2) Run a standard handle service and set up a web-based administrative  
interface.  There are two variations on this choice:
  a) clients send their authentication details to your web service  
which would then authenticate using those credentials to the handle  
service
  b) clients authenticate with your web service using a (non-handle)  
method you select and your web service then authenticates with the  
handle service using your service's (public-key based) authentication


I think 2b is the preferred option as it leaves you free to let both  
individuals (or external groups) be administrators for handles that  
you can also update using your service.

Thanks,
Sean



_______________________________________________
Handle-Info mailing list
Handle-Info@cnri.reston.va.us
http://www.handle.net/mailman/listinfo/handle-info