使用 Microsoft Active Directory 的 Oracle 数据库企业用户和角色?

Dav*_*eto 5 oracle authentication windows linux active-directory

我们有一个遗留应用程序,我们可以完全访问源代码和运行它的平台,因此如果需要,几乎可以实施任何更改。

该应用程序是一个 Java Swing 重量级 GUI(桌面),通过 JDBC 以 2 层方式直接访问数据库。在应用程序启动时,用户输入由用户和密码组成的他/她的凭据。当前的安全架构是:

  • 带有 Oracle Internet Directory 10g (OID) 的 Oracle Database 10g Enterprise(迁移到 11g)。
  • Oracle 使用企业用户,因此在连接到 DB 时,连接中提供的用户来自 GUI,Oracle 会根据 OID 进行验证。
  • 数据库权限通过企业角色进行管理。DB 中定义的每个 ER 映射 OID 中定义的组,因此用户 DB 对对象(表、过程...)的访问由他/她在 OID 中所属的组控制。
  • 多个 GUI 用户可以创建其他用户,因此在 OID 中创建它们,分配到相应的 OID 组以授予 DB 权限。这是使用 OID 中对该“超级用户”的特殊 Oracle 权限来完成的。这是使用标准 LDAP API 从 GUI 完成的,而不是 OID API。GUI 用户使用其凭据连接到 OID 并执行 LDAP 操作。

这个想法是用 Microsoft Active Directory 替换 OID,因此数据库将根据 AD 验证用户。ER 中定义的 DB 权限也可以根据用户所属的组从 AD 中检索。

假设 Oracle DB 11g 和 MS Windows Server 2008(或更高版本,如果需要),这可能吗?

限制/注意事项:

  • Oracle 安装在 Linux 上,通常是 RH。
  • 不能使用 Oracle Virtual Directory,也不能使用任何身份管理 Oracle 产品,只能使用 Oracle DB Enterprise。
  • GUI 应用程序在带有 AD 的 Windows 域中已经存在的 Windows 工作站上执行,儿子可以使用他们的操作系统凭据而不是 GUI 使用的自定义用户,但这必须在 Java(支持的任何版本)中完成。
  • SSL,证书不是首选方式,因为它们需要进行配置。
  • 带有 MS KDC 的 Kerberos 也不是首选方式。
  • AD患者的新的安全模式可能会导致较少的安全环境,但是这是可以接受的。
  • 最好不要将第三方产品添加到安全架构中。
  • Oracle DB - Oracle 和 Microsoft 应支持 MS AD 集成。

我们需要有类似安装经验的人提供一些关于 Oracle - AD 解决方案是否可行的建议。欢迎提供一些指导和步骤!

kev*_*kio 1

我维护的应用程序做了类似的事情,对于大约 100 个用户来说独立于数据库操作系统,但方式更简单。用户由应用程序进行身份验证并从数据库进行授权。详细信息如下:

  • 用户表格,包括他们的电子邮件和启用/禁用状态
  • 所有 AD 组的表,这些组具有特定前缀以指示它们是应用程序组(例如:APP_ADMINS、APP_USERS)
  • 包含组/用户链接的表格

下一部分是同步信息。在我们的组织中,如果添加新用户或更改现有用户的权限,IT 人员会在早上完成这项工作。应用程序通常有一个夜间低使用率的窗口(即:不是每天 24 小时/使用)。

在应用程序 Web 服务器上,我们有一个 Windows 服务来同步组和用户。晚上,我在数据库上运行一个预定作业,该作业会截断组用户链接,并通过使用 DBMS_LDAP 直接查询 Active Directory 来重新创建它们。

出于您的目的,您可能需要编写一个更复杂的包,其中包含一个运行三个 LDAP 查询的数据库包来同步组、用户和组用户,而不是我的截断解决方案。

我发现 DBMS_LDAP 很强大,但文档很少。如果 IT 部门碰巧更改了用户所在的 OU,您将无法从 Oracle 端获得大量有用的信息。

Tim 的网站对本文非常有用,这里有我重复使用的代码。

编辑:使用应用程序有两个部分:

  • 你是谁?(身份验证)如果您不提供 Active Directory 中列出的名称和密码,则您将无法通过登录页面。
  • 你可以做什么?(授权)这里权限的粒度范围很广。我们将自己限制在工作单元的一部分上的一组基本操作:读取、更新、分配其他用户、取消分配其他用户。我们的权限不是那么细化,因此可以表述为“用户 X 在此表上进行了选择”。更好的说法是“用户 X 如果被分配,可以更新文件的这一部分”。

这在一定程度上是由应用程序驱动的。它根据需要创建到数据库的池连接。用户登录应用程序,但以具有所需所有权限的共享用户身份连接到数据库。

进入更详细的示例:用户 X 登录。他们的用户名和密码与 Active Directory 中的用户名和密码相匹配。身份验证后,他们将被带到主页。在此期间,应用程序会查询数据库以了解该用户拥有哪些权限并将其缓存在内存中。主页面加载每个子工作区。每个区域都会询问缓存的权限: - “您有权查看该区域吗?”。如果是这样,则显示工作区域。- “您有编辑该区域的权限吗?” 如果是这样,则显示编辑/创建链接。

Edit2:原始海报评论说

我们正在尝试将应用程序的用户权限复制到数据库对象的数据库权限。

对我来说,这听起来像是一个方钉/圆孔问题。您的业​​务逻辑可能被定义为用户 X 需要在此表上进行选择,但如果您询问用户,他们正在使用该应用程序。他们需要能够处理应用程序显示的任何内容。通常对表和视图以及自定义过滤器进行分组以显示用户在应用程序中需要的内容。这就是为什么某些应用程序发现在应用程序级别强制执行授权更容易。您的应用程序需要在 Active Directory 中复制数据库权限的原因是什么?