企业官网建设流程全解析

高端网站开发公司,绍兴企业网站开发,中山建设,叙述一个网站开发的流程OpenDistro Security 中 backend_roles 的设计哲学 1.OpenDistro Security 的特殊设计 #x1f50d;为内部用户 模拟 外部用户的组关系 2.为什么这样设计#xff1f;#x1f914;设计目的#xff1a;让内部用户也能利用角色映射机制 3.实际使用场景对比 #…OpenDistro Security 中 backend_roles 的设计哲学1.OpenDistro Security 的特殊设计 为内部用户 模拟 外部用户的组关系2.为什么这样设计设计目的让内部用户也能利用角色映射机制3.实际使用场景对比 3.1 场景一标准 Elasticsearch 做法3.2 场景二OpenDistro 做法4.权限计算流程 5.OpenDistro vs 原生 Elasticsearch 对比 ⚖️6.OpenDistro 设计的优点与缺点 7.实际用例为什么需要这个功能用例批量权限调整8.混合使用模式 ️9.关键理解要点 10.一句话总结 11.实战验证 ✨场景一用户 → Roles用户 → Backend roles → Roles场景二用户 → Roles用户 → Backend roles ❌ Roles场景三用户 → Roles用户 ❌ Backend roles → Roles场景四用户 → Roles用户 ❌ Backend roles ❌ Roles场景五用户 ❌ Roles用户 → Backend roles → Roles场景六用户 ❌ Roles用户 ❌ Backend roles → RolesOpenDistro Security 的backend_roles字段设计比较特殊与原生 Elasticsearch 的行为有所不同。1.OpenDistro Security 的特殊设计 在 OpenDistro Security现在叫 OpenSearch Security中backend_roles字段的作用是为内部用户 “模拟” 外部用户的组关系角色映射配置OpenDistro Security 设计外部系统实际不存在假装来自外部系统假装来自外部系统匹配规则1匹配规则2内部用户配置backend_roles 字段手工填写组名角色映射引擎想象中的LDAP组captains想象中的LDAP组starfleet角色映射规则匹配规则1: captains → command_role规则2: starfleet → officer_role用户获得 command_role最终权限 直接角色 映射角色2.为什么这样设计设计目的让内部用户也能利用角色映射机制在标准的 Elasticsearch 中内部用户 → 直接分配角色外部用户 → 通过后端角色映射角色OpenDistro 的想法“为什么不让内部用户也能享受角色映射的灵活性”3.实际使用场景对比 3.1 场景一标准 Elasticsearch 做法// 内部用户直接分配角色PUT/_security/user/kirk{password:kirkpass,roles:[command_officer,starship_captain]// 没有 backend_roles 字段}3.2 场景二OpenDistro 做法// 内部用户利用角色映射PUT_opendistro/_security/api/internalusers/kirk{password:kirkpass,backend_roles:[captains,starfleet],attributes:{rank:captain,assignment:enterprise}// 不直接分配角色}// 角色映射配置PUT_opendistro/_security/api/rolesmapping/command_role{backend_roles:[captains]}PUT_opendistro/_security/api/rolesmapping/officer_role{backend_roles:[starfleet]}4.权限计算流程 角色映射引擎OpenDistro Security用户 kirk角色映射引擎OpenDistro Security用户 kirk找到captains → command_rolestarfleet → officer_role最终权限 command_role officer_role登录 (kirk/kirkpass)验证内部用户密码获取 kirk 的 backend_roles[captains, starfleet]查找映射规则返回角色[command_role, officer_role]认证成功授予权限5.OpenDistro vs 原生 Elasticsearch 对比 ⚖️特性OpenDistro Security原生 Elasticsearchbackend_roles字段内部用户可以设置用于角色映射内部用户通常不设置只在角色映射 API 中使用权限管理方式鼓励使用角色映射统一权限管理内部用户直接分配外部用户通过映射灵活性内部用户权限可通过映射规则统一调整内部用户需要逐个修改混淆度容易混淆内部/外部用户边界概念清晰职责分离6.OpenDistro 设计的优点与缺点 优点✅统一管理所有用户都通过角色映射管理权限。✅动态调整修改映射规则影响所有相关用户。✅属性扩展可以结合attributes字段做更复杂的映射。缺点❌概念混淆模糊了内部用户和外部用户的界限。❌安全性手工填写backend_roles可能出错。❌维护复杂需要维护额外的映射关系。7.实际用例为什么需要这个功能用例批量权限调整# 场景所有舰长需要新权限# 传统方式修改每个舰长用户的角色-用户 kirk:添加 new_command_privileges-用户 picard:添加 new_command_privileges-用户 sisko:添加 new_command_privileges# ... 需要修改几十个用户# OpenDistro 方式修改一条映射规则角色映射规则:-captains → command_role,new_command_privileges# 所有 backend_roles 包含 captains 的用户自动获得新权限8.混合使用模式 ️OpenDistro 还支持混合模式PUT_opendistro/_security/api/internalusers/spock{password:spockpass,opendistro_security_roles:[science_officer],// 直接分配backend_roles:[starfleet,vulcan],// 映射分配attributes:{species:vulcan,logic_level:high}}权限计算science_officer (starfleet映射的角色) (vulcan映射的角色)9.关键理解要点 不是真正的 “后端”OpenDistro 中的backend_roles并不真的来自后端系统而是手工配置的标签。两层角色分配第一层opendistro_security_roles直接分配第二层backend_roles→ 通过映射间接分配设计哲学差异Elasticsearch内部用户和外部用户应该分开管理。OpenDistro所有用户都应该能用统一的方式管理权限。10.一句话总结 在 OpenDistro Security 中内部用户的backend_roles是一个 “虚拟标签”让它能够像外部用户一样通过角色映射机制获得权限从而实现更灵活的统一权限管理。这种设计与原生 Elasticsearch 不同是 OpenDistro/OpenSearch 团队为了简化权限管理而做出的设计选择。11.实战验证 ✨本小节针对下面 6 种场景进行验证。场景一用户 → Roles用户 → Backend roles → Roles用户xiaoming-01会获得test-02的权限可以读log-开头的索引。但没有权限读非log-开头的索引会报错no permissions for [indices:data/read/search] and User [namexiaoming-01, backend_roles[apple-01], requestedTenantnull]。场景二用户 → Roles用户 → Backend roles ❌ Roles虽然apple-01未与test-02关联但xiaoming-01直接与test-02关联仍然拥有权限读取log-开头的索引。场景三用户 → Roles用户 ❌ Backend roles → Roles虽然xiaoming-01未与apple-01关联但xiaoming-01直接与test-02关联仍然拥有权限读取log-开头的索引。场景四用户 → Roles用户 ❌ Backend roles ❌ Roles相当于没有 Backend roles用户xiaoming-01直接与test-02关联拥有读取log-开头索引的权限。场景五用户 ❌ Roles用户 → Backend roles → Roles虽然用户xiaoming-01没有直接与test-02关联但是他们通过apple-01作为 “桥梁” 进行了关联用户xiaoming-01将拥有读取log-开头索引的权限。场景六用户 ❌ Roles用户 ❌ Backend roles → Roles此种情况下用户xiaoming-01根本没有与test-02关联起来自然是没有权限的。