SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场setup-auth

setup-auth

安全与审计

查看项目

更新于 10-15 13:58

技能介绍

用途

setup-auth 用于为 Power Pages 代码站点配置身份验证（登录/登出）和基于角色的授权。当用户提出“设置身份验证”“添加登录”“添加登出”“添加登录入口”“启用认证”“添加基于角色的访问”“添加授权”等需求时使用。

主要能力

  • 支持多种身份提供程序：Microsoft Entra ID、Entra External ID（面向客户应用，支持自助注册）、OpenID Connect（Okta、Auth0 等）、SAML2、WS-Federation、本地身份验证（用户名/密码）、Microsoft Account、Facebook、Google。
  • 可选功能：邀请制注册、条款与条件接受。
  • 有意不搭建 Power Pages 内置 2FA，因为 SendCode/VerifyCode 页面为服务端渲染，无法集成到 SPA 体验中，建议改用 IdP 级别的 MFA。
  • 生成认证服务、类型声明、授权工具、认证 UI 组件，以及适配站点框架和所选身份提供程序的基于角色的访问控制模式。

核心原则

  • 客户端认证仅用于用户体验——Power Pages 认证在服务端进行（会话 Cookie）。客户端角色检查控制用户看到什么，而非能访问什么；实际安全由服务端表权限强制执行。
  • 框架适配模式——每个认证产物（hooks、composables、services、directives、guards）必须匹配检测到的框架惯例。
  • 开发一致性——包含本地开发用的模拟数据，使开发者无需部署到 Power Pages 即可测试认证流程和基于角色的 UI。
  • 保持站点完整性——在更改导航、认证页面、对话框或基于角色的 UI 前，需阅读站点修改完整性参考文档；在所有已配置的语言资源中同步可见的认证状态，保持双向且可扩展。

使用方式

前置条件：

  • 已通过 /create-site 创建现有 Power Pages 代码站点。
  • 站点必须至少部署过一次（.powerpages-site 文件夹必须存在）。
  • 必须通过 /create-webroles 创建 Web 角色。

工作流程：

  • 阶段 1：检查前置条件——验证站点存在、检测框架、检查 Web 角色、发现现有认证配置。
  • 阶段 2：规划——收集认证需求（可选先设置 IDP 应用注册，默认引导式，或在支持的情况下通过提供程序自身 CLI 配置：Okta / Auth0 / Entra External ID），并提交计划供批准。
  • 阶段 3：创建认证服务——包含登录/登出和类型声明的认证服务。
  • 阶段 4：创建授权工具——角色检查函数和包装组件。
  • 阶段 5：创建认证 UI——集成到导航中的登录/登出按钮。
  • 阶段 6：实现基于角色的 UI——将基于角色的模式应用到站点组件。
  • 阶段 7：验证认证设置——验证所有认证文件存在、构建成功、认证 UI 渲染。
  • 阶段 8：审查与部署——总结和部署提示。

阶段 1 细节：

  • 在当前目录或直接子目录中查找 powerpages.config.json；未找到则提示先用 /create-site 创建站点。
  • 读取 package.json 确定框架（React、Vue、Angular 或 Astro）。
  • 查找 .powerpages-site 文件夹；未找到则提示站点需先部署至少一次。
  • 在 .powerpages-site/web-roles/ 中查找 Web 角色 YAML 文件，编译现有 Web 角色列表（名称、id、标志）。
  • 发现现有认证配置：扫描 .powerpages-site/site-settings/ 中已配置的提供程序，按文件名模式匹配 OIDC、SAML2、WS-Federation、社交 OAuth、本地认证；读取每个提供程序的 .sitesetting.yml 文件提取 Authority / MetadataAddress、ClientId / AppId、AuthenticationType、Caption 或显示名称、{Name} slug。通过 Authority URL 模式区分 Entra ID 变体：https://login.windows.net/{guid}/（无 /v2.0/）为 Microsoft Entra ID（workforce）；https://{subdomain}.ciamlogin.com/{tenantId}（无尾部 /v2.0/）为 Entra External ID；https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/v2.0/{policy} 为 Azure AD B2C（旧版）；其他 OIDC authority 为通用 OIDC。
  • 扫描现有 SPA 认证代码：src/services/authService.ts 或 .js（查找 AUTH_PROVIDERS 数组或旧版单一 AUTH_PROVIDER 常量）、src/types/powerPages.d.ts、src/utils/authorization.ts、认证组件（AuthButton.、Login.、Registration.、RedeemInvitation. 等）、src/pages/Login.tsx。
  • 向用户展示发现结果，并询问如何处理现有提供程序：保留所有现有提供程序并添加新提供程序（推荐）、保留所有现有提供程序（本次不添加新提供程序）、用新配置替换所有内容。

阶段 2 细节：

  • 智能认证推断：在询问用户前，根据站点上下文（站点名称、用途、受众类型）推断合适的认证设置。例如内部/员工门户推荐 Entra ID + 仅邀请注册；面向客户的门户推荐 Entra External ID + 开放注册；合作伙伴门户推荐 Entra ID + 仅邀请注册；带受保护功能的公共站点推荐 Entra External ID + 开放注册 + 可选 Google/Facebook；贷款/金融/银行门户推荐 Entra External ID + 仅邀请注册。若能自信推断，则展示推荐及理由并询问是否继续。
  • 收集需求：选择要构建的认证功能（登录+登出 / RBAC / 两者）。处理重新运行：keep-only 模式跳过新提供程序选择；keep-and-add 模式询问要添加什么（多选，现有提供程序不在列表中）；replace-all 模式按首次调用运行提供程序选择。

适用场景

适用于需要为 Power Pages 代码站点添加登录/登出、基于角色的访问控制、多种身份提供程序集成、邀请制注册或条款接受的开发场景。

限制

  • 需要已存在的 Power Pages 代码站点，且至少部署过一次。
  • 需要已创建 Web 角色才能进行基于角色的授权。
  • 不搭建 Power Pages 内置 2FA，建议使用 IdP 级别 MFA。
  • 客户端角色检查不构成实际安全边界，实际安全依赖服务端表权限。
  • 关于具体收费、价格、平台支持范围等更多信息，资料中暂未提供。