DataHub 元数据服务认证体系深入解读Actor、Authenticator 与双层认证架构【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahubDataHub 在元数据服务datahub-gms内部引入了完整的认证子系统使后台请求不再默认受信任。本文以 docs/authentication/concepts.md 为骨架结合仓库源码逐层拆解 Actor、Authenticator、AuthenticatorChain、双层认证提取/强制架构、AuthenticationContext、Access Token 与 Token Service 等核心概念并给出 Guest 认证的完整配置与实操指南。读完本文你将掌握 DataHub 认证链路的工作原理、配置方法与扩展自定义 Authenticator 的完整方案。认证子系统的核心概念为了在元数据服务中实现认证DataHub 引入了一组相互关联的概念组件Actor发起请求的主体身份抽象Authenticator负责校验入站请求的可插拔认证组件AuthenticatorChain串行执行的一串 AuthenticatorTwo-Tier Authentication System将认证提取与认证强制解耦的双层架构AuthenticationContext贯穿请求生命周期的认证状态容器DataHub Access Token元数据服务颁发的访问令牌DataHub Token Service生成与校验令牌的服务组件下面逐一深入。Actor平台内的唯一身份/主体Actor是认证子系统中用于表示正在平台上发起动作例如读写请求的唯一身份/主体的概念。它由两个属性刻画Type类型发起请求的 Actor 类型用于区分用户user与服务service等不同主体。目前仓库中正式支持的类型只有USER对应源码ActorType枚举。Id标识Actor 在 DataHub 内的唯一标识即其他系统中的principal委托人。对用户而言它代表唯一的username该用户名在从 Actor 概念转换为元数据实体 Urn如 CorpUserUrn时被使用。例如root 超级用户 datahub 的属性如下{ type: USER, id: datahub }在进行元数据检索时映射为 CorpUser Urnurn:li:corpuser:datahub在源码层面Actor与Authentication包含 Actor 凭证对象的构建贯穿认证链路例如 AuthenticationExtractionFilter.java 中创建匿名身份时即通过new Actor(ActorType.USER, ANONYMOUS_ACTOR_ID)构造一个USER类型的匿名 Actor。Authenticator可插拔的认证组件Authenticator是元数据服务内部的一个可插拔组件负责在给定请求上下文当前为请求头的情况下认证入站请求。认证的本质归结为成功解析出一个与该请求关联的Actor。存在多种类型的 Authenticator例如校验访问令牌真实性令牌由 DataHub 自身或第三方 IdP 签发针对远程数据库如 LDAP校验用户名/密码凭证该抽象的核心目标是可扩展性extensibility可以针对组织独特需求开发自定义 Authenticator。接口定义在 Authenticator.java其中init(config, context)接收自由格式配置 Mapauthenticate(AuthenticationRequest)返回认证结果或抛出异常。DataHub 默认内置 3 个 AuthenticatorDataHubSystemAuthenticator使用共享的系统标识system client id与密钥system client secret验证入站请求是否源自 DataHub 内部。该 Authenticator 始终存在无法移除——从 AuthenticationExtractionFilter.java 可以看到在认证启用时它被无条件注册进链中。DataHubTokenAuthenticator校验入站请求的Authorization头中是否携带 DataHub 签发的 Access Token见下文。若启用元数据服务认证该 Authenticator 为必需。DataHubGuestAuthenticator在启用 Guest 认证且配置了访客用户时允许未认证用户以指定访客用户身份执行操作。默认禁用如需启用必须显式开启并重启 datahub-gms 服务。其实现见 DataHubGuestAuthenticator.javaenabled配置为false时直接抛出AuthenticationException(Guest Authentication is disabled)否则返回以guestUser为 Actor id 的认证结果。AuthenticatorChain串行执行认证器链AuthenticatorChain是一系列按顺序逐个执行的Authenticator。它允许多种认证方式并存例如通过 LDAP或本地密钥文件都能通过认证。只有当链中每一个Authenticator 都认证失败时请求才会被拒绝一旦某个 Authenticator 成功返回认证结果链路立即短路short-circuit并返回该结果。链路行为在 AuthenticatorChain.java 中实现逐个遍历注册的 Authenticator捕获异常并记录失败信息任一返回非 null 即终止全部失败则返回 null。AuthenticationExpiredException令牌过期会被直接向上抛出以便透传错误信息而普通异常仅记录日志。对应单元测试见 AuthenticatorChainTest.java。Authenticator 链在元数据服务的application.yaml中通过authentication.authenticators配置authentication: .... authenticators: # Configure the Authenticators in the chain - type: com.datahub.authentication.Authenticator1 ... - type: com.datahub.authentication.Authenticator2 ....从源码看AuthenticationExtractionFilter.buildAuthenticatorChain()会先注册内置的DataHubSystemAuthenticator再遍历application.yaml中配置的authenticators列表通过Class.forName(type)反射实例化要求类提供零参构造函数并调用init()后注册进链此外还会扫描 auth 插件目录datahub.plugin.auth.path加载并注册启用的 Authenticator 插件见 AuthenticationExtractionFilter.java 与 registerPlugins。当元数据服务认证被禁用authentication.enabledfalse时链路会被替换为一个刻意放行的NoOpAuthenticator保证所有请求无需认证即可通过——这正是认证默认关闭、opt-in 开启的实现基础。双层认证系统提取与强制解耦DataHub 采用双层认证系统two-tier authentication system将认证信息提取与认证强制彻底解耦。第一层Authentication Extraction认证提取AuthenticationExtractionFilter是面向元数据服务每个请求都会运行的 Servlet 过滤器继承自OncePerRequestFilter标注Order(Ordered.HIGHEST_PRECEDENCE)即最高优先级、最先执行。其唯一职责包括三点提取认证信息构造并调用AuthenticatorChain处理凭证设置通用上下文为每个请求都建立AuthenticationContext绝不强制从不阻断请求——认证失败时设置匿名上下文并继续放行对应源码 AuthenticationExtractionFilter.java过滤器中构造AuthenticationRequest携带 servlet path 与全部请求头调用authenticatorChain.authenticate(...)成功则AuthenticationContext.setAuthentication(authentication)失败或令牌过期则创建匿名认证并设置最后在finally中调用AuthenticationContext.remove()清理线程局部状态。第二层Authentication Enforcement认证强制第二层由多种强制机制组成AuthenticationEnforcementFilter默认的强制过滤器其行为见 AuthenticationEnforcementFilter.java选择性处理仅处理需要认证的端点通过excludedPathPatterns排除/health、/config等路径。排除规则来自authentication.excludedPaths配置逗号分隔支持通配/*前缀匹配基于上下文的决策读取第一层写入的AuthenticationContext若为 null 或 Actor id 等于匿名标识ANONYMOUS_ACTOR_ID即判定为未认证请求阻断当路径需要认证而身份缺失时返回401 Unauthorized其他强制手段解耦设计带来了灵活的强制策略多个强制过滤器不同区域可挂载专用过滤器例如管理区域过滤器附带额外权限检查控制器级强制各 Controller 可自行读取AuthenticationContext并执行自身规则自定义授权逻辑业务逻辑可基于已建立的上下文做认证/授权决策该过滤器被应用到 GraphQL Servlet、Rest.li Servlet 与 AuthtokenServlet 三类端点。双层架构的收益职责解耦认证提取与强制决策分离性能无论强制逻辑多复杂每个请求只做一次认证处理灵活性过滤器、控制器、自定义逻辑等多种强制策略可并存可扩展性新增强制机制无需改动提取层一致性系统各部分访问同一份认证上下文渐进式披露Progressive Disclosure作为附带收益端点可根据用户认证状态返回不同响应AuthenticationContext贯穿请求生命周期的通用认证状态AuthenticationContext是基于线程本地存储thread-local的机制作为提取层与强制层之间的桥梁是整个请求生命周期的通用认证状态认证对象保存认证提取流程的结果Actor 凭证匿名支持提取不到有效凭证时设置为匿名 Actor请求生命周期由提取层自动建立每个请求结束后自动清理通用访问过滤器、控制器、自定义业务逻辑均可访问同一份认证信息正是这个上下文保证了无论强制发生在 Servlet 过滤器、Controller 方法还是自定义业务逻辑中它们都使用提取阶段建立的同一份认证信息从而保证整个系统认证决策的一致性。DataHub Token Service 与 Access Token伴随元数据服务认证引入的新组件DataHub Token Service肩负两项职责生成授予元数据服务访问权限的Access Token校验呈现给元数据服务的 Access Token 的有效性Access Token采用 JSON Web Token 形式——一种无状态令牌具有有限生命周期并使用唯一签名进行验证。JWT 可内嵌一组 claims。Token Service 签发的令牌包含以下 claimsexp令牌过期时间versionDataHub Access Token 版本用于演进当前为 1type令牌类型当前为SESSION用于 UI 会话或PERSONAL用于个人访问令牌actorType与令牌关联的Actor类型当前仅支持USERactorId与令牌关联的Actor的 id目前 Token Service 仅支持对称签名方式HS256来生成与校验令牌。当前 Access Token 在两种场景下由 Token Service 签发UI 登录用户登录 DataHub UI例如通过 JAAS 或 OIDC时datahub-frontend服务代表登录用户向元数据服务发起请求生成 SESSION 令牌只有 frontend 服务被授权执行此操作。生成个人访问令牌用户在 UI 中请求生成 Personal Access Token 时。会话与个人令牌的申请、管理流程详见 personal-access-tokens.md。启用元数据服务认证后的请求方式元数据服务认证是opt-in的默认关闭。启用方式与请求形态见 introducing-metadata-service-authentication.md为datahub-gms与datahub-frontend容器设置环境变量METADATA_SERVICE_AUTH_ENABLEDtrue或在application.yaml中设authentication.enabledtrue、在 frontend 的application.config中设metadataService.auth.enabledtrue强烈建议自行提供authentication.tokenService.signingKey与authentication.tokenService.salt对应环境变量DATAHUB_TOKEN_SERVICE_SIGNING_KEY/DATAHUB_TOKEN_SERVICE_SALT启用后所有请求需携带访问令牌Authorization: Bearer access-tokenUI 用户登录后浏览器 cookie 内部含有效令牌前端会自动提取并随请求发送程序化访问如 ingestion则推荐用 root datahub 用户生成 Personal Access Token配置到datahub-restsink 的token字段中。Token Service 的工厂装配见 DataHubTokenServiceFactory.java底层有状态校验逻辑由StatefulTokenService承担。如何启用 Guest 认证Guest 认证的配置分布在两个配置文件中DataHub frontend 的application.conf与 GMS 的application.yaml。启用步骤为 GMS 与 frontend 两个服务都设置环境变量GUEST_AUTHENTICATION_ENABLEDtrue并重启服务启用后默认访客用户名为guest。该用户必须被显式创建并分配权限以便控制访客用户的权限范围一个推荐的落地路径先创建一个带登录凭证的专属访客账号并保持 guest 访问关闭借此配置并测试该用户的精确权限确认权限设置正确后再开启 guest 访问——此时无需登录/凭证但权限保持已验证的设置。可调参数GUEST_AUTHENTICATION_USER修改指定访客用户名默认guestGUEST_AUTHENTICATION_PATH以访客身份认证的入口 URL默认/publicFrontendapplication.conf相关配置#application.conf ... auth.guest.enabled ${?GUEST_AUTHENTICATION_ENABLED} # The name of the guest user id auth.guest.user ${?GUEST_AUTHENTICATION_USER} # The path to bypass login page and get logged in as guest auth.guest.path ${?GUEST_AUTHENTICATION_PATH} ...GMSapplication.yaml相关配置——注意enabled为 true 时必须配置#application.yaml # Required if enabled is true! A configurable chain of Authenticators ... authenticators: ... - type: com.datahub.authentication.authenticator.DataHubGuestAuthenticator configs: guestUser: ${GUEST_AUTHENTICATION_USER:guest} enabled: ${GUEST_AUTHENTICATION_ENABLED:false} ...对应源码 DataHubGuestAuthenticator.java 表明init()从 configs 读取guestUser默认guest与enabled默认false认证时若未启用直接抛异常启用则无条件返回以访客用户为 Actor 的认证对象——因此 Guest 认证下任何未认证请求都会以访客身份放行权限控制完全依赖为访客账号预先配置的策略。扩展阅读认证架构总览introducing-metadata-service-authentication.md个人访问令牌personal-access-tokens.mdJAAS 登录配置guides/jaas.mdOIDC SSO 配置guides/sso/configure-oidc-react.md默认凭证修改changing-default-credentials.md认证相关核心源码metadata-service/auth-filter/提取与强制过滤器、metadata-service/auth-impl/Authenticator 链与各 Authenticator 实现、metadata-auth/auth-api/Authenticator 接口定义【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 DataHub 元数据服务认证体系深入解读：Actor、Authenticator 与双层认证架构
DataHub 元数据服务认证体系深入解读Actor、Authenticator 与双层认证架构【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahubDataHub 在元数据服务datahub-gms内部引入了完整的认证子系统使后台请求不再默认受信任。本文以 docs/authentication/concepts.md 为骨架结合仓库源码逐层拆解 Actor、Authenticator、AuthenticatorChain、双层认证提取/强制架构、AuthenticationContext、Access Token 与 Token Service 等核心概念并给出 Guest 认证的完整配置与实操指南。读完本文你将掌握 DataHub 认证链路的工作原理、配置方法与扩展自定义 Authenticator 的完整方案。认证子系统的核心概念为了在元数据服务中实现认证DataHub 引入了一组相互关联的概念组件Actor发起请求的主体身份抽象Authenticator负责校验入站请求的可插拔认证组件AuthenticatorChain串行执行的一串 AuthenticatorTwo-Tier Authentication System将认证提取与认证强制解耦的双层架构AuthenticationContext贯穿请求生命周期的认证状态容器DataHub Access Token元数据服务颁发的访问令牌DataHub Token Service生成与校验令牌的服务组件下面逐一深入。Actor平台内的唯一身份/主体Actor是认证子系统中用于表示正在平台上发起动作例如读写请求的唯一身份/主体的概念。它由两个属性刻画Type类型发起请求的 Actor 类型用于区分用户user与服务service等不同主体。目前仓库中正式支持的类型只有USER对应源码ActorType枚举。Id标识Actor 在 DataHub 内的唯一标识即其他系统中的principal委托人。对用户而言它代表唯一的username该用户名在从 Actor 概念转换为元数据实体 Urn如 CorpUserUrn时被使用。例如root 超级用户 datahub 的属性如下{ type: USER, id: datahub }在进行元数据检索时映射为 CorpUser Urnurn:li:corpuser:datahub在源码层面Actor与Authentication包含 Actor 凭证对象的构建贯穿认证链路例如 AuthenticationExtractionFilter.java 中创建匿名身份时即通过new Actor(ActorType.USER, ANONYMOUS_ACTOR_ID)构造一个USER类型的匿名 Actor。Authenticator可插拔的认证组件Authenticator是元数据服务内部的一个可插拔组件负责在给定请求上下文当前为请求头的情况下认证入站请求。认证的本质归结为成功解析出一个与该请求关联的Actor。存在多种类型的 Authenticator例如校验访问令牌真实性令牌由 DataHub 自身或第三方 IdP 签发针对远程数据库如 LDAP校验用户名/密码凭证该抽象的核心目标是可扩展性extensibility可以针对组织独特需求开发自定义 Authenticator。接口定义在 Authenticator.java其中init(config, context)接收自由格式配置 Mapauthenticate(AuthenticationRequest)返回认证结果或抛出异常。DataHub 默认内置 3 个 AuthenticatorDataHubSystemAuthenticator使用共享的系统标识system client id与密钥system client secret验证入站请求是否源自 DataHub 内部。该 Authenticator 始终存在无法移除——从 AuthenticationExtractionFilter.java 可以看到在认证启用时它被无条件注册进链中。DataHubTokenAuthenticator校验入站请求的Authorization头中是否携带 DataHub 签发的 Access Token见下文。若启用元数据服务认证该 Authenticator 为必需。DataHubGuestAuthenticator在启用 Guest 认证且配置了访客用户时允许未认证用户以指定访客用户身份执行操作。默认禁用如需启用必须显式开启并重启 datahub-gms 服务。其实现见 DataHubGuestAuthenticator.javaenabled配置为false时直接抛出AuthenticationException(Guest Authentication is disabled)否则返回以guestUser为 Actor id 的认证结果。AuthenticatorChain串行执行认证器链AuthenticatorChain是一系列按顺序逐个执行的Authenticator。它允许多种认证方式并存例如通过 LDAP或本地密钥文件都能通过认证。只有当链中每一个Authenticator 都认证失败时请求才会被拒绝一旦某个 Authenticator 成功返回认证结果链路立即短路short-circuit并返回该结果。链路行为在 AuthenticatorChain.java 中实现逐个遍历注册的 Authenticator捕获异常并记录失败信息任一返回非 null 即终止全部失败则返回 null。AuthenticationExpiredException令牌过期会被直接向上抛出以便透传错误信息而普通异常仅记录日志。对应单元测试见 AuthenticatorChainTest.java。Authenticator 链在元数据服务的application.yaml中通过authentication.authenticators配置authentication: .... authenticators: # Configure the Authenticators in the chain - type: com.datahub.authentication.Authenticator1 ... - type: com.datahub.authentication.Authenticator2 ....从源码看AuthenticationExtractionFilter.buildAuthenticatorChain()会先注册内置的DataHubSystemAuthenticator再遍历application.yaml中配置的authenticators列表通过Class.forName(type)反射实例化要求类提供零参构造函数并调用init()后注册进链此外还会扫描 auth 插件目录datahub.plugin.auth.path加载并注册启用的 Authenticator 插件见 AuthenticationExtractionFilter.java 与 registerPlugins。当元数据服务认证被禁用authentication.enabledfalse时链路会被替换为一个刻意放行的NoOpAuthenticator保证所有请求无需认证即可通过——这正是认证默认关闭、opt-in 开启的实现基础。双层认证系统提取与强制解耦DataHub 采用双层认证系统two-tier authentication system将认证信息提取与认证强制彻底解耦。第一层Authentication Extraction认证提取AuthenticationExtractionFilter是面向元数据服务每个请求都会运行的 Servlet 过滤器继承自OncePerRequestFilter标注Order(Ordered.HIGHEST_PRECEDENCE)即最高优先级、最先执行。其唯一职责包括三点提取认证信息构造并调用AuthenticatorChain处理凭证设置通用上下文为每个请求都建立AuthenticationContext绝不强制从不阻断请求——认证失败时设置匿名上下文并继续放行对应源码 AuthenticationExtractionFilter.java过滤器中构造AuthenticationRequest携带 servlet path 与全部请求头调用authenticatorChain.authenticate(...)成功则AuthenticationContext.setAuthentication(authentication)失败或令牌过期则创建匿名认证并设置最后在finally中调用AuthenticationContext.remove()清理线程局部状态。第二层Authentication Enforcement认证强制第二层由多种强制机制组成AuthenticationEnforcementFilter默认的强制过滤器其行为见 AuthenticationEnforcementFilter.java选择性处理仅处理需要认证的端点通过excludedPathPatterns排除/health、/config等路径。排除规则来自authentication.excludedPaths配置逗号分隔支持通配/*前缀匹配基于上下文的决策读取第一层写入的AuthenticationContext若为 null 或 Actor id 等于匿名标识ANONYMOUS_ACTOR_ID即判定为未认证请求阻断当路径需要认证而身份缺失时返回401 Unauthorized其他强制手段解耦设计带来了灵活的强制策略多个强制过滤器不同区域可挂载专用过滤器例如管理区域过滤器附带额外权限检查控制器级强制各 Controller 可自行读取AuthenticationContext并执行自身规则自定义授权逻辑业务逻辑可基于已建立的上下文做认证/授权决策该过滤器被应用到 GraphQL Servlet、Rest.li Servlet 与 AuthtokenServlet 三类端点。双层架构的收益职责解耦认证提取与强制决策分离性能无论强制逻辑多复杂每个请求只做一次认证处理灵活性过滤器、控制器、自定义逻辑等多种强制策略可并存可扩展性新增强制机制无需改动提取层一致性系统各部分访问同一份认证上下文渐进式披露Progressive Disclosure作为附带收益端点可根据用户认证状态返回不同响应AuthenticationContext贯穿请求生命周期的通用认证状态AuthenticationContext是基于线程本地存储thread-local的机制作为提取层与强制层之间的桥梁是整个请求生命周期的通用认证状态认证对象保存认证提取流程的结果Actor 凭证匿名支持提取不到有效凭证时设置为匿名 Actor请求生命周期由提取层自动建立每个请求结束后自动清理通用访问过滤器、控制器、自定义业务逻辑均可访问同一份认证信息正是这个上下文保证了无论强制发生在 Servlet 过滤器、Controller 方法还是自定义业务逻辑中它们都使用提取阶段建立的同一份认证信息从而保证整个系统认证决策的一致性。DataHub Token Service 与 Access Token伴随元数据服务认证引入的新组件DataHub Token Service肩负两项职责生成授予元数据服务访问权限的Access Token校验呈现给元数据服务的 Access Token 的有效性Access Token采用 JSON Web Token 形式——一种无状态令牌具有有限生命周期并使用唯一签名进行验证。JWT 可内嵌一组 claims。Token Service 签发的令牌包含以下 claimsexp令牌过期时间versionDataHub Access Token 版本用于演进当前为 1type令牌类型当前为SESSION用于 UI 会话或PERSONAL用于个人访问令牌actorType与令牌关联的Actor类型当前仅支持USERactorId与令牌关联的Actor的 id目前 Token Service 仅支持对称签名方式HS256来生成与校验令牌。当前 Access Token 在两种场景下由 Token Service 签发UI 登录用户登录 DataHub UI例如通过 JAAS 或 OIDC时datahub-frontend服务代表登录用户向元数据服务发起请求生成 SESSION 令牌只有 frontend 服务被授权执行此操作。生成个人访问令牌用户在 UI 中请求生成 Personal Access Token 时。会话与个人令牌的申请、管理流程详见 personal-access-tokens.md。启用元数据服务认证后的请求方式元数据服务认证是opt-in的默认关闭。启用方式与请求形态见 introducing-metadata-service-authentication.md为datahub-gms与datahub-frontend容器设置环境变量METADATA_SERVICE_AUTH_ENABLEDtrue或在application.yaml中设authentication.enabledtrue、在 frontend 的application.config中设metadataService.auth.enabledtrue强烈建议自行提供authentication.tokenService.signingKey与authentication.tokenService.salt对应环境变量DATAHUB_TOKEN_SERVICE_SIGNING_KEY/DATAHUB_TOKEN_SERVICE_SALT启用后所有请求需携带访问令牌Authorization: Bearer access-tokenUI 用户登录后浏览器 cookie 内部含有效令牌前端会自动提取并随请求发送程序化访问如 ingestion则推荐用 root datahub 用户生成 Personal Access Token配置到datahub-restsink 的token字段中。Token Service 的工厂装配见 DataHubTokenServiceFactory.java底层有状态校验逻辑由StatefulTokenService承担。如何启用 Guest 认证Guest 认证的配置分布在两个配置文件中DataHub frontend 的application.conf与 GMS 的application.yaml。启用步骤为 GMS 与 frontend 两个服务都设置环境变量GUEST_AUTHENTICATION_ENABLEDtrue并重启服务启用后默认访客用户名为guest。该用户必须被显式创建并分配权限以便控制访客用户的权限范围一个推荐的落地路径先创建一个带登录凭证的专属访客账号并保持 guest 访问关闭借此配置并测试该用户的精确权限确认权限设置正确后再开启 guest 访问——此时无需登录/凭证但权限保持已验证的设置。可调参数GUEST_AUTHENTICATION_USER修改指定访客用户名默认guestGUEST_AUTHENTICATION_PATH以访客身份认证的入口 URL默认/publicFrontendapplication.conf相关配置#application.conf ... auth.guest.enabled ${?GUEST_AUTHENTICATION_ENABLED} # The name of the guest user id auth.guest.user ${?GUEST_AUTHENTICATION_USER} # The path to bypass login page and get logged in as guest auth.guest.path ${?GUEST_AUTHENTICATION_PATH} ...GMSapplication.yaml相关配置——注意enabled为 true 时必须配置#application.yaml # Required if enabled is true! A configurable chain of Authenticators ... authenticators: ... - type: com.datahub.authentication.authenticator.DataHubGuestAuthenticator configs: guestUser: ${GUEST_AUTHENTICATION_USER:guest} enabled: ${GUEST_AUTHENTICATION_ENABLED:false} ...对应源码 DataHubGuestAuthenticator.java 表明init()从 configs 读取guestUser默认guest与enabled默认false认证时若未启用直接抛异常启用则无条件返回以访客用户为 Actor 的认证对象——因此 Guest 认证下任何未认证请求都会以访客身份放行权限控制完全依赖为访客账号预先配置的策略。扩展阅读认证架构总览introducing-metadata-service-authentication.md个人访问令牌personal-access-tokens.mdJAAS 登录配置guides/jaas.mdOIDC SSO 配置guides/sso/configure-oidc-react.md默认凭证修改changing-default-credentials.md认证相关核心源码metadata-service/auth-filter/提取与强制过滤器、metadata-service/auth-impl/Authenticator 链与各 Authenticator 实现、metadata-auth/auth-api/Authenticator 接口定义【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考