The issue here is that you have the concept of "users" in two distinct RDBMS systems. Unfortunately, RDBMS products use literal (as opposed to Reference) style identifiers to denote their domain entities (users, tables, views, procedures, roles etc..).
The solution requires middleware that's endowed with the following capabilities:
concept or domain entity denotation (naming) using Reference style of identifiers (e.g., HTTP URIs where <#OracleUserID> and <#SQLServerUserID> denote Oracle and SQL Server users, respectively)
ability to express and comprehend entity relationship semantics (e.g., that two entities are participants in a coreference relation whereby <#SQLServerUserID> <#sameAs> <#OracleUserID> where <#sameAs> denotes the aforementioned relation)
ability to create data access policies driven by entity relationship semantics thereby enabling mapping of DBMS roles and associated privileges between SQL Server and Oracle
ODBC of JDBC connectivity such that your clients access the capabilities described above via ODBC or JDBC while also communicating with Oracle and SQL Server via ODBC or JDBC.
To conclude, if you are happy to apply middleware to this solution, you can take a look at OpenLink Virtuoso which offers the capabilities described.
Disclaimer: I'm the founder/CEO of openlink software