如何配置 authentik 访问请求实现带审批和自动过期的临时访问【免费下载链接】authentikThe authentication glue you need.项目地址: https://gitcode.com/GitHub_Trending/au/authentik当你不希望管理员提前为每个用户固定开通应用权限而是让成员在需要时自己发起申请、由指定审阅人审批、到期后自动收回可以使用 authentik 的访问请求Access requests功能。配置完成后用户通过用户界面的Discover页发起申请审阅人审批通过后权限按设定的时长授予到期由 authentik 自动撤销整个过程的创建、批准、拒绝、撤销都会记录为事件。需要注意的前提来自功能文档的标注该功能标记为 Enterprise 功能且文档标注为2026.8版本的 preview 特性可用性以你的实例版本和企业许可为准。你需要一个管理员账号用于配置一个已存在的目标应用以及至少一个愿意担任审阅人的用户或组。完整配置路径见 访问请求文档。访问请求的完整生命周期在动手配置前先明确这条链路后文每步对应其中一个环节用户在Discover页选择可申请的应用可附带选择应用权限项entitlement。authentik 根据绑定到该应用的请求规则评估申请。如果配置了请求流request flow先运行它可用来收集申请理由等信息。审阅人按规则配置收到通知申请出现在其待审队列中。审阅人批准或拒绝。申请人不能批准自己的申请。批准后authentik 授予访问权限并开始计时。到期后 authentik 自动撤销访问。创建请求规则请求规则决定使用哪个请求流、谁可以审阅、审阅人如何被通知。以管理员登录 authentik打开 Admin interface。进入ApplicationsRequest rules。点击New Request Rule设置以下字段Rule Name规则名称。Minimum reviewers批准一条申请所需的最少审阅人数量。Minimum reviewers is per-group可选启用后每个绑定的审阅组各自需要满足该数量禁用时该数量是所有审阅组的总和。Notify选择新申请的接收方式三选一Everyone who can approveOnly individually-selected reviewersA random subset (of size “minimum reviewers”) of everyone who can approveNotification transports可选用于通知审阅人的通知传输方式支持本地UI 内、Email、Webhook通用及 Slack/Discord。Request flow可选用户提交申请时呈现的请求流。点击Create Request Rule。绑定审阅人一个容易踩空的点请求规则如果没绑定任何用户、组或策略结果是没有任何人能批准针对该规则的请求这与“未绑定则人人可申请”的申请侧规则相反。在ApplicationsRequest rules中点击规则名旁的箭头展开规则。点击Create or bind...。选择负责审阅该规则下申请的用户、组或策略可以绑定任意数量。把应用设为可申请并设置过期时长这一步同时完成两件事让应用出现在Discover页以及设定临时访问的有效期上限——“自动过期”就体现在这里。进入ApplicationsApplications点击要设为可申请的应用名称。打开Request rules标签页点击Create or bind...选择Bind existing rule然后设置Rule使用的请求规则。Pending expiry申请保持待审状态的最长时间超时未批未拒会自动失效lapse。Maximum granted expiry经此绑定批准的授权最长可保持多久。申请人可以要求更短但不能要求更长。Additional entitlements可选批准时随应用访问一起授予的应用权限项。点击Create Request Rule Binding。可选限定谁可以发起申请在应用的Request rules标签页展开某条规则点击名称旁的箭头点击Create or bind...选择可以通过该规则申请此应用的用户、组或策略。这里沿用应用访问的约定如果请求规则绑定上没有绑定任何用户、组或策略则所有用户都有资格申请该应用的访问。可选配置请求流收集申请理由提交申请会执行一个请求流。你可以用它收集申请理由justification、在提权前要求重新认证或 MFA或对申请人运行策略。请求流可以在两个位置设置请求规则本身的Request flow字段品牌brand上的请求流作为请求规则未指定时的回退。品牌配置见 Branding 文档。authentik 自带一个空的default-request流定义见 blueprints/default/flow-default-request-flow.yamlslug 为default-requestdesignation 为stage_configuration你可以按需给它添加所需的 stage 和策略。申请人在请求流中输入的 prompt 数据会显示在审阅人一侧的Requester notes字段中。如果不需要用户交互请求流可以留空。验证配置文档给出的验证路径如下用一个没有该应用访问权限的测试用户登录。打开Discover页在Browse标签下确认目标应用以可申请卡片形式出现。点击该应用提交一条访问申请确认它出现在审阅人的For My Review标签队列中。审阅人点击Review批准申请可附Notes然后确认访问已授予且对应的事件已记录。审阅人在队列中可以看到申请人、所申请的应用和申请提交以来的时长申请人则可以在Discover页的My Requests标签查看自己的待审申请。管理员还可以通过ApplicationsAccess Requests页面查看所有申请每行包含申请人、创建时间、所申请应用和状态展开行可以看到Requester Data申请人在请求流中填写的全部 prompt 数据和Targets。如果该管理员账号本身被设为相关请求规则的审阅人还能点击Fulfill直接批准或拒绝。到期回收与审计事件批准后访问是带时限的到期 authentik 自动撤销无需手工清理。申请链路的每个阶段都会记录为事件可用于 event matcher 策略匹配access_request_createdaccess_request_approvedaccess_request_deniedaccess_request_revoked如需在批准、拒绝等事件发生时提醒安全团队可以把 event matcher 策略和通知规则配对通过 Slack、邮件或 webhook 发出参考 Events。限制与常见现象功能文档明确列出的限制用户不能批准自己的申请。批准的访问是有时限的过期时长应与实际工作所需时间匹配。请求规则依赖策略策略配置失误可能导致请求没有符合条件的审阅人。文档给出的故障对照表现象原因与解决应用不出现在可申请列表中该用户未绑定到应用上的请求规则绑定request rule binding。申请没有审阅人应用未绑定规则、绑定的策略未通过或唯一匹配到的审阅人就是申请人本人。审阅人无法处理申请审阅人就是申请人或未被请求规则的绑定匹配到。【免费下载链接】authentikThe authentication glue you need.项目地址: https://gitcode.com/GitHub_Trending/au/authentik创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考