Multi-auth tools (was Re: WebID for developers)

Thanks Jürgen.

This seems another example of the "Abstract Authentication + Plugins"
strategy/pattern Michael Mahemoff referred to on G+.

I already mentioned everyauth for node.js, Michael points out Omniauth (Ruby)

https://github.com/intridea/omniauth#readme

https://plus.google.com/u/0/106413090159067280619/posts/hbPszAsJ3r3

Maybe it's worth collecting a list of these on the Wiki somewhere, so
if someone's developing a new implementation they can target an
existing abstraction rather than making it a one-off.

Cheers,
Danny.

On 15 March 2012 14:00, Jürgen Jakobitsch <j.jakobitsch@semantic-web.at> wrote:
> hi danny,
>
> with WebIDRealm [1][2] your scenario is doable,
> at least if you're working on a tomcat-servlet-container.
>
> WebIDRealm is completely analog to any other tomcat-realm [3] (MemoryUserDatabase, JNDI Realm,..)
> and lets you define roles (as with any other realm, save the fact, that the roles are not strings, but URIs).
>
> wkr turnguard
>
>
> [1] http://webid.turnguard.com/WebIDTestServer/docs/installation (please note that the doc is still incomplete, how to gain rdfa support is missing, but will be fixed during the next couple of days)
> [2] https://sourceforge.net/p/webidrealm/
> [3] http://tomcat.apache.org/tomcat-6.0-doc/config/realm.html
>
> ----- Original Message -----
> From: "Danny Ayers" <danny.ayers@gmail.com>
> To: public-rww@w3.org
> Sent: Thursday, March 15, 2012 1:45:59 PM
> Subject: WebID for developers
>
> I spent this morning catching up with the docs and it seem to me
> there's something missing. Something to directly answer a scenario
> like this:
> [[
> I'm a developer building a new blogging service.
> I want to allow three kinds of access to the service: Admin (someone
> who can manage the service), User ( post to a blog) and Public (anyone
> can comment on posts).
>
>      I've heard WebID is a Good Idea, but how do I use this in my application?
> ]]
> (Requirements like this are pretty common in the current generation of
> Web application/service/sites, but a blogging service with those
> particular controls is an uncomplicated example)
>
> As it happens I am (more or less) that developer. For a piece of app
> I'm working [1] on I want this kind of facility. Over the past few
> weeks I've been reading and asking around the alternatives. Two
> guiding principles: 1.make it easy for the end user 2. wherever
> possible follow good practices. Three aspects stand out:
> authentication, authorization and sessions.
>
> === Authentication ===
> Generally we're talking about having a username-password pair or
> something similar that are known by the user and the service but
> no-one else.
> The list of possible approaches is pretty long. First question is
> whether to handle this locally or delegate it to another service.
> Check the list for everyauth [2] - there are loads of existing
> services that can be used. But for doing things locally, at the top of
> the list are:
> * HTTP Basic - simple, but insecure
> * HTTP Digest - more secure, but problematic for the user (e.g.
> browser must be closed to log out)
> Asking around (on G+) the consensus seemed to be that Digest was more
> trouble than it was worth, and that probably the best approach was:
> * Basic over HTTPS - apparently combines the best features of the above.
>
> So where does WebID fit in this?
>      If I wanted to do everything locally, what are my options?
>      Are there any 3rd parties I can delegate to? (hi Kingsley :)
>
> === Authorization ===
> Once we have some kind of shared secret, the question become one of
> how to use this to control access to resources. Assuming a setup like
> the LAMP stack, the auth data might be stored in something like LDAP
> or more probably a DB table. Some secured code will compare requests
> with what's in the table, maybe responding with a redirect where the
> user hasn't the right credentials.
> But if we're talking about WebID, the data about the user will be in RDF.
>      So would a triplestore really be necessary for management of
> WebID-based authorization?
>      How do I do it on LAMP?
>
> Ok, I personally am working against triplestores anyhow, so for me
> that particular question isn't so relevant. But it still isn't plain
> sailing, there's a bit of a conflict between the semwebby
> everything-linked mindset and having resources protected by an ACL.
> How do you provide granular access to graphs where some of the data
> will be private? With my little app I'm trying to do as much of the
> data access (R/W) as possible using SPARQL 1.1. When you're trying to
> provide access with granular control, it starts to look rather
> difficult. The reading of data can be contained by using a lot of
> smallish graphs with individual access control, and using (maybe
> temporary) CONSTRUCTed graphs against which to fire the actual
> queries. But when it comes to writing...well I haven't quite figured
> that bit out yet. (In practice I'm assuming that the complexity of
> access wiring needed will be a direct function of the complexity of
> the ACL, so for something like the blogging scenario won't actually be
> too bad - i.e. it isn't necessary to solve for the general case).
>
> === Sessions ===
> Ok, this is a fly in the ointment. There's conflict between best
> practices and usability (with the current generation of browsers at
> least). An awful lot of sites/services out there use the idea that you
> login in and the server remembers you are logged in until you log out.
> Very user-friendly. But they don't follow the RESTful approach of
> sending complete messages (including auth) for each request. Typically
> cookies interact with server state. While I've been looking into this
> I've seen no end of claims of "RESTful authentication" that are
> actually just cookie based setups that happen to use systematic naming
> schemes for URIs. (And a RESTful API seems to be defined as anything
> supports PUT and DELETE, but that's another story...).
>
>      So how can WebID be used in a system that follows best
> practices, while still being user-friendly?
>
> Although a purist answer would be nice here, perhaps more useful for
> adoption would be a pragmatic one which starts with WebID but then
> leads to cookie-based sessions.
>
> I started looking into this because I wanted to do auth with 1. make
> it easy for the end user 2. wherever possible follow good practices,
> but really what I'm asking here is about 3. make it easy for the
> site/service developer. Personally one reason I was looking at other
> techniques before WebID was because I'm frightened of anything
> involving signing. I do see how WebID ties nicely in with the whole
> practical linked data Web etc etc notion which I'm enthusiastic about
> - but one look at those message path diagrams and I'm scared! (I just
> discovered some node.js code [3] so that should break the ice for the
> app I'm working on).
>
> One of the big obstacles to adoption of semweb tech is the perception
> that it's complicated (thanks RDF/XML!). Reasonably secure
> authentication, authorization etc. does have an unavoidable level of
> complexity no matter how it's done, but right now I think it'd be fair
> to say WebID looks a lot harder than it is.
>
> Cheers,
> Danny.
>
> [1] https://plus.google.com/b/102910670341143019851/102910670341143019851/posts/2f2Duq4LDzu
> [2] https://github.com/bnoguchi/everyauth#readme
> [3] http://magnetik.github.com/node-webid-report/
>
> --
> http://dannyayers.com
>
> http://webbeep.it  - text to tones and back again
>
>
> --
> | Jürgen Jakobitsch,
> | Software Developer
> | Semantic Web Company GmbH
> | Mariahilfer Straße 70 / Neubaugasse 1, Top 8
> | A - 1070 Wien, Austria
> | Mob +43 676 62 12 710 | Fax +43.1.402 12 35 - 22
>
> COMPANY INFORMATION
> | http://www.semantic-web.at/
>
> PERSONAL INFORMATION
> | web       : http://www.turnguard.com
> | foaf      : http://www.turnguard.com/turnguard
> | skype     : jakobitsch-punkt
> | xmlns:tg  = "http://www.turnguard.com/turnguard#"



-- 
http://dannyayers.com

http://webbeep.it  - text to tones and back again

Received on Thursday, 15 March 2012 13:29:48 UTC