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