3:48 p.m.
Hell all,
There is still a lot of confusion about security floating around. After another office
conversation on Friday, it would be best to have an open discussion.
First some perspective. MetaMatrix documentation described the securitizing process in
layers (an expanded version of this will be added to the Teiid docs):
1. Be selective about what metadata is imported - only modeled items can be accessed.
Most if not all customers do this.
2. Change the physical metadata - e.g. mark a table as non-updatable - this is enforced
regardless. Some customers would do this.
3. Mark models as non-visible if users should not have access to them. This could be set
at design time or on the vdb. Advanced customers would do this.
4. Apply data roles at deploy-time to visible models. With roles/entitlement checking
turned on a server is "locked down", since we are deny by default. Roles must
be created for every VDB to provide any access. A few customers would do this.
To clarify how permissions are applied, please see the MetaMatrix documentation or
http://docs.jboss.org/teiid/7.1.0.Final/reference/en-US/html_single/#enti... for an
updated explanation. In short, permissions are applicable to every visible resource and
only checked against what is accessed by the top level of the user query. If visible
virtual model B uses visible virtual model A which in turn accesses non-visible physical
Z, then both A and B both should have roles/permissions applied because they are visible -
B does not use the permissions of A. Z does not need roles/permissions because it cannot
be targeted by a user query regardless.
It has been asserted there is an inherent security flaw with this approach. That is
simply not true. Since we are deny-by-default, adding visible models (such as B) to a VDB
is NOT "insecure" until the Designer user (or deployer in MetaMatrix) adds
permissions to the applicable data roles. Even then the notion of insecure would be based
around the idea that permissions have been added inconsistently - for example, a
particular column value from Z is readable in A, but not B. As often as not this could be
described as a feature. This "application level" style of security makes it
easy to present transformed values that would be otherwise be inaccessible with granular
permissions.
I became aware the other day that we are changing the default visibility on physical
models. Just to make sure we understand that change better, please consider that having
the default of physical models as non-visible only makes usage of VDBs without data roles
(the majority use case) harder. It does not make vdbs with data roles more secure. Since
we are deny by default, someone still has to take an explicit action to make a new model
accessible when using roles. There is also an issue that any virtual update procedure is
not a perfect substitute for a performing an update on a physical table. Virtual update
procedures support insert into with a queryexpression 1 row at a time and do not allow
referencing columns of view in either values or criteria. Forcing the use of virtual
layers is not the right approach, it is merely a recommendation based upon the ease of use
of the design-time visibility setting.
With that said there have been a couple of issues raised relevant to security:
TEIID-1220 - came about because of discussions with Paul where it was clear that breaking
with legacy will help usability. Specifically having data role checking turned on
requires every VDB to have roles, since this is now a design time and not a deploy time
operation, it is especially onerous to go back and add roles as an afterthought to
existing VDBs. The simple fix is to turn data role checking on by default and to only
check roles if a vdb has them. This will be targeted to 7.1.1. An additional feature
would be the ability to turn off role checking on a VDB through a managed property.
TEIIDDES-568 - SYS and pg_catalog schemas are not yet covered by the data-role editor.
TEIIDDES-577 - should non-visible models not be shown in the data-role editor?
In these latter cases there are a couple of alternative approaches that may help clarify
some of the security confusion. The first observation is that the visibility mechanism is
no longer easy to differentiate since both visibility and data roles are set at design
time. A possible simplification is to not use the coarse grained notion of visibility for
data access restrictions. Instead if a user wants to make a model (or any resource
non-visible) that would be the same as creating a data role ("default") that
does not have permissions for model. That role would need a mapping or a boolean
attribute to denote that any authenticated user has the role.
Visibility checking is applied differently than roles - visibility also limited what is
returned through the system tables and is also considered at resolving time (a non-visible
table reference must be fully qualified). I can find no precedent for roles having a
similar effect. That is all entries will be visible in metadata and resolvable against
partial names and "SELECT *". There are other examples of being able to mark a
table as hidden, which means that it will not show up in the system metadata but is
otherwise accessible. If we do apply visibility likewise, then the visibility role
concepts are distinct.
Steve