User Guide > Publishing Resources > Security and Privileges on Published Resources
 
Security and Privileges on Published Resources
Using a published resource requires appropriate access privileges on both a published resource and the original resource. A published resource has its own READ and WRITE privileges to let you manipulate it in Studio, but it does not have its own run-time privileges (EXECUTE, SELECT, INSERT, UPDATE, DELETE). You can set up privileges for the published and shared areas in Studio to suit the needs and restrictions of your environment. For more information on how to set up various privileges, refer to the TDV Administration Guide.
Privileges on objects in the Data Source are evaluated only at the time of introspection or later when a FETCH is called during statement execution. So if privileges on an object in the data source are lowered after introspection, the error will not be caught until actual statement execution.
Column-based security privileges are set up the same way as for any other object exposed through TDV. If you restrict access to a view in the published layer, the shared area, and in the introspected data source, the column would have the same restrictions. Similarly if you mask the data in a column for a view, that data is masked in the same way for the published data.
How resource security and privileges work for a given TDV environment can vary. It is best to test several scenarios to make sure that you can access resources as expected. You can publish a table as a database, as a view through a web service, or as a view through a legacy web service, so you should check all scenarios.
When you run a SELECT * from an external client, the likely results are:
An error message states that you do not have appropriate privileges on a column in your query.
You get a result that contains ONLY the columns that you have privilege to see.
The columns for which you do not have privileges have all NULL values.
You can control which of these outcomes occurs using a configuration parameter.
Controlling the Outcome of Trying to Access a Column without Permissions
You can control which of the outcomes occurs using a configuration parameter.
To control what is returned for a column for which the user lacks appropriate permissions
1. From the Studio main menu, select Administration > Configuration.
2. In the Configuration window, navigate to Server > Configuration > Security > Enable Exception For Column Permission Deny.
3. Set this parameter to true if you want to raise an exception when column-level permissions are missing.
4. Set or leave this parameter set to false, if you want columns for which the user does not have permissions to contain NULLs or not be returned at all.