Symantec IGA

 View Only
Expand all | Collapse all

Oracle DB connector missing object permissions, other than execute

  • 1.  Oracle DB connector missing object permissions, other than execute

    Posted Sep 30, 2016 04:31 PM



    Is there a way to utilize the rudimentary Out-of-the-Box standard oracle database connector to actually manage oracle permissions other than execute on database objects?


    Business Use Case:

    Please correct me if I’m wrong, but is CA Services or GD really required every time CA IdM is used to provision to a standard oracle database (nothing custom), because it seems like this would be a standard configuration, and something tackled before, like connecting to ms sql server, for instance. I’ve searched the community, and ca documentation, but haven’t found any crib notes, or any documentation surrounding how CA’s customers’ have pervasively utilized this oracle db connector to manage oracle db users.  If I’m not mistaken, the ootb oracle connector has been a part of CA IdM provisioning since CA IdM 8.1SP2 and I'm sure this isn't the first time this topic has come up.



    CA IdM 12.6 latest SP

    Oracle 11.0.2 G SE


    How common is it for a CA IdM customers’ to utilize the OOTB Oracle connector within provisioning to manage Oracle db’s native users (within the database) and their permissions on object types in the db instance? If it’s common, even somewhat common, or even rare, is there any blog, crib notes, tech doc or any supplemental documentation on what steps were taken to comprehensively secure objects associated with the provisioned oracle database instance user.  


    Perhaps it’s much more common for CA IdM oracle custom connectors to some custom tables utilized for authentication of some third party application who’s backend uses oracle (meaning they’re simply provisioning to tables within oracle, not actually managing db users for the oracle database instance), which doesn't help us? 


    Possible Workarounds / Solutions:

    Without relying on Enhancement to CA IdM


    Option 1:

    Perhaps from an oracle dba perspective, has anyone had any experience recommending or utilizing oracle groups, or roles, so that when a basic db user is provisioned from CA IdM, it'll automatically inherit the appropriate rights within the instance, so long as is it’s setup as part of that group or role, which would need to be setup and managed within oracle, outside of the ca product. Wouldn’t something like this allow oracle users, with those necessary group identifiers, to inherit those necessary base permissions. Perhaps the oracle db could be setup in a way to help ensure that the user will fit into some of the predefined groups / roles that govern the other permissions, other than "execute", within oracle.


    Option 2:

     completely custom connector to attempt to manage more permissions on oracle objects through a connector xpress project.


    Submit Enhancement Request to Product Management:


    I'm all for helping to improve the product and will submit an enhancement if that's my only option, but hasn’t this enhancement been requested before since this is such an old problem? If so, what was the outcome and what benefit will submitting another enhancement do to help fix the problem of not being able to manage oracle db user permissions on objects, other than execute.

  • 2.  Re: Oracle DB connector missing object permissions, other than execute

    Posted Oct 03, 2016 03:50 PM

    You would need to open an Idea in the communities.


    Here is what the product documentation says


    Security, Configuration, and Limitations - CA Identity Management & Governance Connectors - CA Technologies Documentatio… 


    Limitation: Connector Cannot Manage Some Privileges

    You cannot use the Oracle connector manage the following operations:

    • Manage system privileges or object privileges that apply to Oracle accounts
    • Manage system privileges or object privileges that apply to Oracle roles

    Instead, use native Oracle administrative tools to work with these privileges.