Re: [Handle-info] Distributed handle administrators

[Scott Yeadon <scott.yeadon@anu.edu.au>]

Hi Sean,

Thanks heaps for the feedback. I did some "whiteboarding" yesterday and 
came to pretty much the same (option 2b) conclusion as it reduces 
options for attacks on the handle system but also provides some level of 
flexibility in authentication mechanisms at the web service level.

Thanks again!

Scott.

Sean Reilly wrote:
> 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