On 08/21/2010 09:48 AM, Steven Hawkins wrote:
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.
What is the current default - update-able
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.
Perhaps moderately advanced. This is presented as best practice in
basic discussions with users as both a security concern and a method to
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
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
I became aware the other day that we are changing the default visibility on physical
models. Just to make
IMO, phys models should remain visible by default. Making invisible
will make initial development/debugging that much more onerous.
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
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.
Agreed. If data role checking is on by default in Teiid, some global
state in the VDB should indicate whether or not it is "participating" in
data role usage. Perhaps that global state is the presence of at least
one role. Perhaps it's a discrete setting. The challenge with only
checking roles if the VDB has them is that a user can assume the system
is locked down because role checking is on but a VDB with no roles
defined will be wide open.
TEIIDDES-568 - SYS and pg_catalog schemas are not yet covered by the
TEIIDDES-577 - should non-visible models not be shown in the data-role editor?
I think non-visible models should show up in data-role editor but should
be identified as non-visible (grayed out or something). If a user is
applying data roles to a model and then later makes a decision to make
the model non-visible, it may be confusing for it to no longer display
in the editor. Also, would roles/permissions be preserved if the
modeler toggles visibility?
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 is more than security. It's encapsulation. I don't think
users should use roles for that purpose - if that's what you're suggesting.
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.
teiid-dev mailing list
Sr. Product Manager
JBoss Middleware Business Unit
Red Hat, Inc