Re: Real Application Security with centrally-managed users

From: Tim Gorman <tim.evdbt_at_gmail.com>
Date: Thu, 15 Feb 2024 11:20:41 -0800
Message-ID: <58111673-aaa9-4784-b505-851d3b410a9b_at_gmail.com>



Timur,

The problem seems to be two different methods of authenticating users which do not appear to intersect.

With CMU, there is callback functionality from Oracle to AD to authenticate a database connection, but nothing for RAS to authorize because RAS wasn't used for the authentication.  I agree that RAS should support AD users, but we can't find out how, so far.  That is the crux of my inquiry.

As a workaround, our team built functionality into an AFTER LOGON trigger to unpack the authenticated CMU information from data-dictionary views to then attempt authentication via RAS as well, but the RAS packaged functions/procedures are AUTHID CURRENT_USER which are prohibited inside an AFTER LOGON trigger, which require AUTHID DEFINER.  I can think of a further workaround to that workaround to address that obstacle, but I don't want to go further down the rabbit-hole of workarounds when it probably should work without any workarounds at all.

Does that make sense?  Please let me what you think?

Thanks!

-Tim

On 2/15/2024 10:35 AM, Timur Akhmadeev wrote:
> Hi Tim,
>
> I know a little bit of CMU and glanced at RAS documentation. My
> understanding is that those two have a few similarities.
>
> CMU is a way to make a transparent authentication and (optionally)
> authorization via roles mappings for end users from AD.
> Depending on your requirements you may configure authorization
> (mapping of the AD roles to DB roles) with CMU, but it is not a
> requirement. You can use just the authentication part, and manage
> authorization manually.
>
> Now the RAS, from what I quickly read, provides a fine grained
> authorization for application users beyond simple roles.
> Most of the docs mention creating apps users in the db via package
> xs_principal, and they also mention the users could be mapped to a
> directory server.
> According to the docs
> <https://docs.oracle.com/en/database/oracle/oracle-database/21/dbfsg/XS_PRINCIPAL-package.html#GUID-AB88CD3F-89B0-4C25-A404-D5C8D7FEB1AD>
> the password for those external users can't be set via set_password
> which makes me think the RAS can work as an authentication mechanism
> in a similar to CMU way. Otherwise, they would have to store passwords
> in the DB.
> So I would say if you're looking at RAS then possibly you don't even
> need CMU, as RAS should be able to support AD users. I haven't touched
> RAS and obviously may be wrong.
>
> HTH
>
> On Wed, Feb 14, 2024 at 12:32 AM Tim Gorman <tim.evdbt_at_gmail.com> wrote:
>
> Friends and colleagues,
>
> I'm working on a problem involving two somewhat obscure -- but
> vitally important -- pieces of functionality in Oracle19c...
>
> * Real Application Security (RAS)
> * Centrally-managed users (CMU)
>
> In general, RAS is the successor to virtual private databases
> (VPDs), which was introduced way back in Oracle8i for fine-grained
> row-level security and column-level security.  CMU is the
> management of database users by a centralized external authority
> such as Microsoft Active Directory, rather than an Oracle DBA
> using CREATE USER commands in each Oracle database.
>
> There is copious documentation and support for either mechanism,
> but I am hard-pressed to find anything indicates that both can be
> used together.
>
> We've already started down the road of devising a custom solution
> for integrating the two, but it is hitting difficulties, so I
> would like to find out if anyone on this list has any experience
> -- or knows of someone who has experience -- using both RAS and
> CMU together?
>
> If anyone from the security or identity-management product groups
> at Oracle could offer any advice, it would be gratefully accepted!
>
> Please let me know what you think?
>
> Thanks!
>
> -Tim
>
>
>
> --
> Regards
> Timur Akhmadeev

--
http://www.freelists.org/webpage/oracle-l
Received on Thu Feb 15 2024 - 20:20:41 CET

Original text of this message