[ https://jira.jboss.org/browse/TEIID-1327?page=com.atlassian.jira.plugin.s... ] Steven Hawkins updated TEIID-1327: ---------------------------------- Fix Version/s: 7.3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/TEIID-1327?page=com.atlassian.jira.plugin.s... ] Steven Hawkins commented on TEIID-1327: --------------------------------------- A possible interface in the Teiid api could be: public interface RoleProvider { public enum PermissionType {CREATE, READ, UPDATE, DELETE}; public Set<String> getInaccessibleResources(PermissionType action, Set<String> resources, CommandContext commandContext); public boolean hasRole(String name, CommandContext commandContext); } I'm assuming that there is only a need to configure a single custom RoleProvider across all of Teiid. The resource names are same table/procedure/column fqn's checked against the built-in Teiid roles. The same user query could consult the getInaccessibleResources multiple times (e.g. for each subquery) - this is just to keep the visitation logic simple. The hasRole function will be used by the hasRole security function. If roles are not defined on a vdb, but a custom RoleProvider is configured (probably based upon mc injection) we would consult that instance instead. If roles are defined on a vdb and a custom RoleProvider is defined, I would be inclined to consult both. An alternative design would be have the interface directly supply a role set (probably defined as a map of role name to DataPolicy instances). However that approach is a little less flexible from an implementation perspective. Any thoughts? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/TEIID-1327?page=com.atlassian.jira.plugin.s... ] Steven Hawkins commented on TEIID-1327: --------------------------------------- This is an alternative (or addition) to the built-in authorization mechanisms. The target use case being that someone doesn't want to statically define the roles/permissions - or at least they want something external consulted. This will not make sense for most deployments, where the current facility for changing the role mappings should be sufficient. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/TEIID-1327?page=com.atlassian.jira.plugin.s... ] Ramesh Reddy commented on TEIID-1327: ------------------------------------- So in the case where VDB roles and RoleProvider are defined then both need to agree on permissions? Or it needs to be agreed by any one of them? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/TEIID-1327?page=com.atlassian.jira.plugin.s... ] Mark Addleman commented on TEIID-1327: -------------------------------------- Thanks, Steven. Having the sql, whether the full sql or the portion currently being evaluated, as the abstract syntax tree would be useful, though not absolutely required. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/TEIID-1327?page=com.atlassian.jira.plugin.s... ] Mark Addleman commented on TEIID-1327: -------------------------------------- Thinking about it more, I would rather have the SQL than not. My preference would be in a pre-parsed form even if it's a non-public API that is subject to change. Second best would be the string form that we could parse if necessary. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/TEIID-1327?page=com.atlassian.jira.plugin.s... ] Mark Addleman commented on TEIID-1327: -------------------------------------- Do you need the ability to override hasRole? - No. In fact, we probably won't use hasRole relying instead on our own Teiid functions and connection information. I have been assuming we would have access to the connection object. Is this fair? -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1327?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-1327: --------------------------------------- Sorry it took me a while to get back to this thread. The CommandContext does not have the connection available. I can make one available to this extension point if needed. Something along the lines of: void validateAccess(Command command, CommandContext context, Connection connection) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1327?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-1327: --------------------------------------- Since the possible implementation path for this relies on a non-public api, I am thinking this should be pushed from 7.4. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1327?page=com.atlassian.jira.plugin... ] Work on TEIID-1327 stopped by Steven Hawkins. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1327?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-1327: --------------------------------------- Perhaps a compromise would be to provide an interface to validate the actual command and a extension point in the config to inject your own instance, but to leave it as an undocumented feature. You could also get a connection that approximates the current session with a local connection that has PassThroughAuthentication turned on. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1327?page=com.atlassian.jira.plugin... ] Steven Hawkins closed TEIID-1327. --------------------------------- -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira