身份和訪問管理用於控制你組織中誰可以使用 Cursor，以及他們可以執行哪些操作。你將配置身份驗證、自動化用戶開通與回收，並通過設備管理來實施策略。
按以下順序配置身份管理控制：
- 配置 SSO：優先完成集中式身份驗證
- 啓用 SCIM：自動化用戶全生命週期管理
- 部署 MDM 策略：強制執行允許的團隊 ID 和擴展
- 分配角色：將管理員權限授予合適的人員
單點登錄 (SSO) 和 SAML¶
SSO 允許你的用戶使用現有的身份提供商在 Cursor 中進行身份驗證。用戶無需創建單獨的 Cursor 密碼，而是使用其企業憑據登錄。
Cursor 支持與 Okta、Azure AD、Google Workspace 和 OneLogin 等提供商配合使用 SAML 2.0。啓用 SSO 後，你可以要求所有團隊成員都必須使用 SSO，並完全阻止基於密碼的身份驗證。
如果你的公司運行多個已關聯的團隊，請通過 Organizations 使用共享的組織級 SSO。團隊級 SSO 仍然受支持，可滿足特定團隊的身份要求。
有關詳細配置說明，請參閱 SSO 和 SAML 設置。
SCIM 預配¶
SCIM 2.0 預配可通過身份提供商自動管理您的團隊成員和目錄組。僅適用於已啓用 SSO 的企業版方案。
未使用 SCIM 時，您需要手動將用戶添加到 Cursor 團隊，並在他們離職時將其移除。使用 SCIM 後：
- 新員工加入相應羣組後，會自動獲得 Cursor 訪問權限
- 離職員工從身份提供商中移除後，會失去訪問權限
- 羣組成員資格變更會自動同步
有關設置說明，請參閱 SCIM 預配。如果您管理多個關聯團隊，還可以在組織級別同步目錄組，並在各團隊間重複使用。請參閱 組織級別身份。
組織級身份¶
如果你有多個已關聯的團隊，可通過Organizations在組織層級統一管理身份。這樣只需一套共享設置，無需爲每個團隊單獨進行身份配置。
- 組織 SSO：爲所有團隊共用一套登錄設置。參見Organizations。
- 組織 SCIM：將目錄組從你的身份提供商同步到 Cursor，再通過組織羣組跨團隊使用。
- 通過羣組管理團隊成員：將目錄組同步到組織羣組，再將該羣組映射到團隊，讓成員資格和團隊角色與該羣組保持一致。參見使用羣組爲團隊提供支持。
- 整合團隊身份提供商：組織管理員可以在儀表盤中，將獨立的團隊級身份提供商合併爲一個共享的組織身份提供商。參見整合團隊身份提供商。
基於角色的訪問控制 (RBAC)¶
Cursor 團隊中有三種角色：成員 (Members) 、管理員 (Admins) 和未付費管理員 (Unpaid Admins) 。
更多信息請參見 成員、角色和席位類型。
MDM 策略¶
移動設備管理（MDM）系統允許你在用戶設備上統一管理並強制執行策略。Cursor 在 macOS 上支持基於 MDM 的策略，在 Windows 上支持通過 Intune / 組策略（Group Policy）實施策略，以確保用戶遵守組織要求。
有關特定平臺的 MDM 配置說明，請參見 Deployment Patterns。
允許的團隊 ID¶
最重要的 MDM 策略之一，是防止用戶在公司設備上登錄個人 Cursor 賬戶。
當你配置允許的團隊 ID 策略時，Cursor 只允許使用這些特定團隊 ID 進行身份驗證。如果用戶嘗試使用其他團隊 ID（例如個人賬戶）登錄，Cursor 會立即將其登出。
例如，如果你的員工使用公司筆記本電腦，你可以將允許的團隊 ID 設置爲你的企業團隊 ID。這樣可以防止他們誤用可能未啓用隱私模式（Privacy Mode）的個人賬戶。
cursorAuth.allowedTeamId Cursor 設置用於控制哪些團隊 ID 被允許登錄 Cursor。該設置接受一個以逗號分隔的團隊 ID 列表，這些團隊 ID 將被授權訪問。
例如，將 cursorAuth.allowedTeamId 設置爲 "1,3,7"，可以讓來自這些特定團隊 ID 的用戶登錄。
當用戶嘗試使用不在允許列表中的團隊 ID 登錄時：
- 會被立即強制登出
- 會顯示一條錯誤信息
- 在使用有效團隊 ID 之前，應用會阻止後續的身份驗證嘗試
要在組織層面集中管理允許的團隊 ID，請在你的設備管理方案中配置 AllowedTeamId 策略。該策略會覆蓋用戶設備上的 cursorAuth.allowedTeamId 設置。此策略的值是一個字符串，其中包含以逗號分隔的已授權團隊 ID 列表。
有關特定平臺的 MDM 配置說明，請參閱 Deployment Patterns。
允許的擴展¶
控制用戶可以在 Cursor 中安裝哪些擴展。擴展可以訪問你的工作區，因此你需要確保只有受信任的擴展可以運行。
工作原理：
extensions.allowed Cursor 設置項用於控制哪些擴展可以被安裝。該設置接受一個 JSON 對象，其中鍵是發佈者名稱或完整的擴展 ID，值是布爾值，用於指示是否允許這些條目。
重要：
extensions.allowed使用允許列表模型。只要你添加了任何條目，就只允許顯式允許的條目，其他所有內容都會被阻止。不存在隱式的”全部允許”回退機制。例如，將extensions.allowed設置爲{"anysphere": false}不僅會阻止 Anysphere 的擴展；它也會阻止其他所有發佈者，因爲允許列表中沒有其他條目。
如果你想在保持其他所有內容都被允許的同時阻止特定擴展，請將 "*": true 通配符與要拒絕的條目一起使用。通配符是最不具體的匹配項，因此發佈者和擴展 ID 條目會覆蓋它：
{
"*": true,
"untrusted-publisher": false
}
要將可安裝範圍限制爲一組已批准的發佈者和擴展，請省略通配符，僅列出你信任的項。你可以包含完整的擴展 ID、固定到特定版本，或固定到某個發佈通道：
{
"anysphere": true,
"github": true,
"esbenp.prettier-vscode": true,
"ms-azuretools.vscode-containers": false,
"dbaeumer.vscode-eslint": ["3.0.0"],
"github.vscode-pull-request-github": "stable"
}
管理員門戶配置：
團隊管理員可以在 團隊儀表盤 的 Security & Identity 部分配置允許的擴展。該配置會自動應用到所有團隊成員的 Cursor 客戶端。將此字段留空會停止向客戶端推送值。
將客戶端重置爲“允許全部”： 清空管理員門戶字段會停止推送新值，但不會移除客戶端已在本地應用的策略。用戶會繼續執行他們收到的最後一個值。要將所有人重置爲允許所有擴展，請先部署
{"*": true}，等待客戶端拉取該值；如果你之後不再希望集中管理此設置，再清空該字段。注意： 要在管理員門戶中使用此功能，需要 Cursor 客戶端版本 2.1 或更高。使用較早版本的用戶將不會被應用擴展限制。
MDM 配置：
要集中管理允許的擴展，請通過你的設備管理解決方案配置 AllowedExtensions 策略。此策略會覆蓋管理員門戶設置以及用戶設備上用戶配置的 extensions.allowed 設置。該值是一個定義允許的發佈者和擴展的 JSON 字符串。
有關特定平臺的 MDM 配置說明，請參見 Deployment Patterns。
.cursor 文件夾¶
當你在 Cursor 中打開一個項目時，編輯器 會在代碼倉庫的根目錄創建一個 .cursor 文件夾。這個文件夾包含：
- 項目特定的設置
- 項目規則和上下文
這個文件夾可以提交到版本控制中。你的團隊成員可以共享規則和設置，但請注意，這些配置對所有有倉庫訪問權限的人都是可見的。
對於訪問權限不由你控制的倉庫，在提交前請先檢查 .cursor 文件夾的內容。不要在規則文件中放入敏感信息。
你也可以在團隊儀表盤中，通過服務器管理規則和命令。
工作區信任¶
security.workspace.trust.enabled Cursor 設置項用於控制是否啓用 Workspace Trust 功能。該設置接受一個布爾值，用於決定在啓用全部功能前，是否提示用戶信任工作區。
例如，將 security.workspace.trust.enabled 設置爲 true 會啓用工作區信任提示，而設置爲 false 則會完全關閉該功能（所有工作區將自動被信任）。
啓用工作區信任後：
- 用戶在首次打開每個新工作區時會被提示是否信任該工作區
- 未被信任的工作區將在受限模式下運行，可用功能受限
- 信任決策會被保存，並在各個工作區中記住
如需在組織層面集中管理工作區信任，請通過設備管理工具配置 WorkspaceTrustEnabled 策略。該策略會覆蓋用戶設備上的 security.workspace.trust.enabled 設置。此策略的值爲布爾值（true 或 false）。
有關特定平臺的 MDM 配置說明，請參見 Deployment Patterns。
高級身份控制功能適用於 Enterprise 版本¶
聯繫團隊，瞭解 SCIM、MDM 策略等更多信息。
