[Mulgara-dev] authentication in Mulgara

[Paul Gearon]

On Sun, Mar 9, 2008 at 2:55 AM, Andrae Muys <andrae at netymon.com> wrote:
>
>  On 09/03/2008, at 2:52 PM, William Mills wrote:
>
>  > I wanted to drop a note to restart the conversation about
>  > authentication in Mulgara.  I know it's in the plan for re-
>  > implementation.  To reiterate the point I was making to Andre over
>  > dinner, lack of any authentication model makes Mulgara a non-
>  > starter at Yahoo and probably many other corporate environments.
>  > It is certainly possible to add an authentication layer in the
>  > application, but that doesn't solve the whole problem.
>  >
>  > If I were king I'd probably offer the standard username/password
>  > authentication model because everyone expects it, but I'd also have
>  > the option of using something less sucky/replayable.
>  >
>  > For authorization/access the common model used for the various SQL
>  > databases is well defined, but I'm not sure how closely it fits
>  > Mulgara.  Certaibnly I'd like to differentiate between a system/
>  > root user and a less priveledged user.  Access control down to the
>  > level of insert/delete from a model would be interesting.  Control
>  > down to the row level that was explored in previous incarnations
>  > is, in my opinion, overkill.

It certainly was, which is how the old "security" identifier ended up
becoming the graph ID.  This also influenced us in deciding that
security should be on a graph-by-graph basis.  If you have some kind
of conceptual difference between two pieces of data such that you feel
you need differing security on them, they they belong in separate
graphs.  You may recall that at the storage and retrieval lever we
treat the graph ID symmetrically with all the other identifiers
(subject, predicate and object) so we have no qualms about giving
every statement its own graph, if you really want to get pathological
about it.  The queries might get messy though.  :-)

>  Well the security api is still there, and has in the past been used
>  to provide control down to the level of per graph insert/delete/
>  query. I know of one bug in the layer that can permit some queries to
>  bypass the query-security, but that can be fixed in a few days, and
>  only hasn't been because we don't currently have anyone using that
>  functionality.
>
>  I must admit I haven't looked at the api for a couple of years now,
>  so I will have to do that before I can really comment much more.

It's all still there, and I even brought it forward into the
Connection API when I wrote this recently.  It will need an audit to
make sure it hasn't been bypassed anywhere in recent years by someone
who wasn't aware of it, but I expect that the majority of it will
still work.

The missing code is a JAAS implementation.  The first prototype used
normal authentication files, but the second version loaded up
everything from an internal graph.  This was surprisingly easy to do.
Since I implemented 90% of the JAAS classes in the first place, it has
been pointed out that I am not the person to re-write this stuff.
(which is a shame, since I know how easy it is).  It took me a week
the first time I did it, and I had to learn how to use JAAS while I
was doing it!  (It's mostly boilerplate implementations of the JAAS
interfaces - so concern about leaving security holes is *mostly*
mitigated by JAAS handling the important stuff for you).  I suggest
that anyone who has the time will not find it challenging.

Paul