Hi all. To add my $0.02 to the debate; I whole-heartedly support the delegated auth model, but suggest we try to tease apart the authentication step on one hand (user proving to the DAS registry who he is), and the authorisation-related things on the other (does the authenticated user have access to a given server, or source within a server, or possibly even more fine-grained controls; user managing/requesting access to sources; and more).
Also, as something of an alternative approach to "heavier" grid security solutions, it may be worth considering a more Web 2.0 style delegated authz approach based on OAuth (http://oauth.net). In the photo sharing-and-printing example scenarios illustrated in the two tutorials referenced below, one could envision the DAS registry as the site where the photos are hosted (the OAuth provider), and the DAS client as the photo-printing site (the OAuth consumer): http://hueniverse.com/2007/10/beginners-guide-to-oauth-part-ii-protocol-workflow/ http://www.wdvl.com/Authoring/Authorization/OAuthIntro/Jaswinder_Singh03042010.html However, I'll admit that it isn't entirely obvious to me how to accommodate the DAS servers themselves as additional players in these scenarios, unless (as Andy's writeup mentions) the servers accepts tokens issued by the registry. The following may be also useful to the discussion. We have an ongoing project in our group where we're exploring a number of scenarios very similar to the delegated model described by Andy, with a central AtomPub server and authz schemes centred on Atom feeds and feed entries (some of which are protected and others which are not). An authz scenario of particular interest involves a standalone application, from which a user with submission privileleges uploads genetic variation data via a RESTful POST to the central Atom store. The relevance to the present discussion that the submission app above can probably be considered as analoguous to a standalone DAS client, and the central Atom store analoguous to the DAS registry. The model we are keen to use for this is very similar to Flickr photo-uploads, where the user authorises the Flickr Uploadr standalone application (http://www.flickr.com/help/tools/) to send photos to Flickr on his behalf. Importantly, the user does not enter user/pwd credentials in the standalone app itself, but rather is sent to the central website where he signs in (if not already authenticated) and authorises the app. Subsequently, the app can upload data to the until de-authorised by the user, or the token expires (if time-limited). This would seem to address the issue Andy listed regarding trusting 3rd party DAS client with one's password. Our aim here is to try and keep the authz/authn sequence simple for users and leverage their familiarity with social networking tools, and also to simplify implementation of the standalone app (BTW there will be several of those, implemented by others) and other Web-based apps connecting securely to the Atom store. Also, we're trying to generally keep things simple implementation-wise and "secure enough" for our purposes, and thus we're trying to avoid deploying full-blown grid security toolkits which would likely be overkill. Whether the same holds for DAS authn/authz in terms of the level of security required and other factors, I don't know at this time, and will leave open for debate. Hope these musings are helpful!! Best regards, Mummi, Leicester -- Gudmundur A. Thorisson, Brookes lab Department of Genetics University of Leicester University Road Leicester, LE1 7RH, UK Tel: +44 (0)116 229 7273 On 13 Apr 2010, at 18:17, Andy Jenkinson wrote: > On 13 Apr 2010, at 17:48, Jim Procter wrote: > >> Thanks for posting this, Andy. >> >> >> On 13/04/2010 14:44, Andy Jenkinson wrote: >>> Afterwards, two proposals emerged: firstly, that the DAS specification make >>> a simple recommendation to use existing HTTP digest authentication, leaving >>> DAS software to implement the components independently. Secondly, a >>> DAS-specific delegated authentication model based around a trusted third >>> party (probably the DAS registry) as the identity provider. >>> >>> Each proposal has its own advantages and disadvantages in terms of both >>> security and implementation considerations which we now need to debate >>> within the community before we come up with a recommendation, so I have >>> summarised both proposals on the wiki: >>> http://www.biodas.org/wiki/DAS1.6E#Authentication >>> >> I didn't participate in the fine details of the discussion last friday, but >> I wondered afterwards if anyone had considered adopting the Globus >> authentication model. Grid based authentication for programmatic web >> services has now been around for a number of years in a number of guises >> (the Globus toolkit is the one I know of), and may already address all the >> requirements and concerns raised at the meeting. >> >> My 2c.. >> Jim. >> >> ps. I can point out some people who may be worth approaching regarding >> Globus or Shibboleth style third-party ident/auth middleware if people wish. > > Definitely worth a shout, I'll do some research. > _______________________________________________ > DAS mailing list > [email protected] > http://lists.open-bio.org/mailman/listinfo/das _______________________________________________ DAS mailing list [email protected] http://lists.open-bio.org/mailman/listinfo/das
