From: | David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Row-level Security vs Application-level authz |
Date: | 2015-02-24 00:39:58 |
Message-ID: | 1424738398373-5839126.post@n5.nabble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Darin Gordon wrote
> I'm trying to understand the extent that row level security in postgresql
> 9.5 may replace, or augment, application-level access control.
>
> I have a fully implemented application-level access control policy. It's
> not clear to me how I will integrate or replace it with RLS.
>
> Craig Ringer mentioned in a blog post:
> "Most importantly, row-security is pluggable – in addition to looking
> policies up from the system catalogs, it’s also possible to use a policy
> hook to supply arbitrary policy from extensions. "
>
> It seems that my options will be to record authorization into the catalog
> or write an extension?
My quick take-away from RLS compared to traditional multi-tenant security
policies is that with RLS you move the security logic into the database and
leverage the native database roles. Your model likely makes use of a single
user associated with an application and that application applies the
security logic during its interactions with the client-users that it
maintains separately.
A session is associated with one user in the database world while your
application can keep track of session state in a much less burdensome manner
and act as a proxy from the database's perspective which allows for somewhat
more flexible resource usage with a significant increase in architecture
complexity.
The disadvantage is that you cannot allow clients to access the database
directly because it has no inherent concept of what they are allowed or not
allowed to see. If you desire that capability then having a secondary
security system based upon RLS would make sense. Otherwise, you'd need to
decide whether adding an additional layer of protection - to catch buggy
coding in the proxy-application security layer - is worth the cost of
introducing end-user (customer) identities into the production database and
having your middle-tier manage connections and sessions with customer
identities instead of its own existing proxy identity.
David J.
--
View this message in context: http://postgresql.nabble.com/Row-level-Security-vs-Application-level-authz-tp5839069p5839126.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2015-02-24 01:01:40 | Re: Row-level Security vs Application-level authz |
Previous Message | Stephen Frost | 2015-02-23 23:34:45 | Re: Row-level Security vs Application-level authz |