主題
- 表單自訂
- 任務範本
- 自訂欄位
- 公式自訂欄位
- Asana時間追蹤
- 綁定
- 相依性類型
- 表單
- 與表單提交者的電子郵件溝通
- 篩選及排序自訂欄位
- 請使用 ID 自訂欄位。
- 表單中的字段映射
- 手動觸發規則
- 請設定規則權限
- 將綁定套用至專案
- 整合雲端儲存和檔案共用的規則
- 執行規則動作
- 分享表單
- 請使用規則中的變數。
- 請在規則中設定日期
- 管理專案範本儀表板
- 使用規則整合和小工具
- 規則整合，提升生產力和溝通
- 運營和支援的規則整合
- 請查看規則執行歷史記錄
- 觸發規則
- 綁定常見問題
- 套件管理和權限
- 全域欄位的管理儀表板
- 整合銷售和服務的規則
- 參考自訂欄位
- 自動變換依存任務的日期
- 自訂欄位類型和限制
- 如何透過應用程式開發介面 (API) 將所有時間輸入資料從 Asana 匯出為 CSV
- 核准
- 工作流程產生器
- 規則
- 專案範本
- 任務相依性
- 規則中的條件和分支
- Microsoft Teams與Asana整合
- Asana for Outlook附加元件
- Asana for Gmail 附加元件
- 在 Asana 中的 Zoom 會議
- 整合 Asana for Tableau
- 整合 Power BI
- Google試算表與Asana
- Google 和 Asana
- Google表單與Asana
- GitHub與Asana整合
- 行事曆與Asana
- Google 日歷 + Asana
- 使用 Asana for Adobe Creative Cloud
- 使用 Google 智慧型方塊
- Instagantt 和 Asana
- 使用 Zapier 和 Asana
- 使用 Vimeo 和 Asana
- 使用 Chrome 擴充功能與 Asana
- 請參閱 Asana for Jira Cloud 常見問題
- 使用 Jira 資料中心
- 自動化和 AI Studio 的 Zoom 轉錄文字
- 使用 AI Studio 建立 Zoom 通話筆記工作流程
- 使用 Tray.io 與 Asana
- 使用 ServiceNow 與 Asana
- Wufoo與Asana
- 啟用 Asana 建立和 Microsoft 365 整合的權限
- Outlook行事曆與Asana
- 網頁表單與Asana
- Zendesk整合
- Asana for Jira Cloud
- 來自Meta的Asana與工作空間
- JIRA資料中心常見問題
- Splunk + Asana
- 在 Asana 中整合 Salesforce
- 應用程式開發介面 (API)
- Claude 中的 Asana 應用程式
- ChatGPT 中的 Asana 應用程式
- 將時間追蹤資料從 Everhour 遷移至 Asana
- 合規性管理：應用程式開發介面 (API) 與整合支援
- Slack 與 Asana
- eDiscovery資源中心
- 多組織部署
- 實施雙因素驗證
- 企業金鑰管理(EKM)
- Asana歐盟資料中心
- HIPAA合規性
- Asana和全球貿易合規
- 如何存取管理主控臺
- 隱私與安全
- 帳戶
- 雙因素驗證
- 服務帳戶
- 設定授權的 SAML 群組對應
- 資料維繫政策
- Asana帳戶電子郵件政策
- 刪除您的 Asana 帳戶
- 多個帳戶和合併
- 在系統管理主控台中管理密碼設定
- 請使用 SAML 群組對應和 SCIM 互動。
- 存取權限
- 在 Asana 中允許 IP 清單
- 合規管理附加元件
- 遵守 FedRAMP 規範
- 權限管理附加元件
- 全域驗證設定
- 自動移除訪客
- 行動應用程式安全權限
- 瞭解使用者角色權限
- 應用程式管理和整合
- 適用於Enterprise版組織的SecureAuth
- 個人資料欄位可編輯性控制項
- 對工作項目申請系統管理員權限
- 使用 SCIM 佈建及取消佈建
- Asana IP 位址範圍和主機名稱
- 系統管理員安全控制項
- Asana日本資料中心
- Asana中的系統管理員和超級管理員角色
- 具有自訂角色的角色型存取控制 (RBAC)
- 如何分離 Asana 帳戶
- Asana 的資料落地
- 使用 SCIM 在 Microsoft Entra ID 中設定 Asana 角色
- 付費方案的驗證和存取管理選項
- 使用 SCIM 在 Okta 中設定 Asana 角色
付費方案的驗證和存取管理選項
預設情況下會使用 Asana 的一般身份驗證，您的組織成員可以選擇使用傳統密碼或 Google 單一登入來登入各自的帳戶。
在付費組織中，超級管理員可選擇成員登入 Asana 的方式、設定密碼複雜度要求，以及強制重設所有成員的密碼。若您購買了 Enterprise、Enterprise+ 版事業處方案，則可同時啟用 SAML。舊版 Enterprise 版層級的事業處也可以啟用 SAML。
付費版驗證設定僅適用於您的組織成員。組織訪客不受驗證設定影響。
喜歡您看到的內容嗎？立即開始免費試用 Asana。免費試用。
密碼強度與強制密碼重設
請參閱此文章，瞭解如何更新密碼強度要求，並強制您的組織重設密碼。
Google 登入
若您的公司使用Google 工作空間進行商業活動或教育，且您使用的是付費版 Asana，您可以要求成員透過 Google 進行驗證。
注意
若您並未使用事業處方案，則無法設定 Google 登入。
若要將組織變更為 Google 登入，請前往系統管理主控台中的安全性標籤頁。從此處前往全域驗證設定，然後按一下 Google 登入。選擇 除訪客外，對所有成員均為必要 ，然後按一下 儲存變更。
變更儲存後，所有與您成員的 Asana 帳戶關聯的密碼即會失效，且成員必須使用 Google 單一登入。
若您需要變更與您的 Google 帳戶關聯的電子郵件網域，請聯絡我們，以便我們將新的網域新增到您的組織。
SAML
若您的公司使用 OneLogin、Okta、LastPass、Azure AD、SecureAuth 或 Active Directory 等身分提供商，則您的 IT 部門可能需要設定 SAML。若要設定 SAML，您必須：
- 隸屬於 Asana Enterprise、Enterprise+ 或舊版 Enterprise 版組織或事業處。
- 成為組織的超級管理員
組織設定 SAML 後，組織成員登入帳戶時便不再需要使用密碼。他們只需在登入頁面中輸入電子郵件，然後點選登入，將密碼欄位留空即可。或者，他們也可以使用 IdP 應用程式儀表板存取 Asana。
第 1 步：設定您的 IDP
若您滿足以上條件，第 1 步就是使用您的身分提供商設定 Asana。下面列出了 OneLogin、Okta、LastPass、Bitium、SecureAuth、Active Directory 和 Entrust Identity 的步驟，但您也可以使用其他身分提供商執行此動作：
Active Directory
參閱此文件，瞭解如何使用 Active Directory 設定 SAML for Asana。
您也可以嘗試使用 Okta Cloud Connect。Okta Cloud Connect 是 Okta 的免費版本，兩者是同一個應用程式。您可以此為一個核心應用程式設定用於 AD 整合和單一登入的 Okta。您可以在此處找到更多資訊。
Azure AD
參閱此文章，瞭解如何使用 Azure AD 設定 SAML for Asana。
Google 工作空間
在此處瞭解如何透過 SAML for Asana 設定 SSO。
LastPass
- 在 LastPass Enterprise 中，首先前往您的 Enterprise Console (主控台)，然後選擇位於頂端的 SAML 標籤。隨後就會轉到 SAML 主頁面
- 點選 Asana 應用程式圖示
- 依循畫面上的指引
- 複製用於兩步驗證的登入 URL 以及 X.509 憑證
Okta
- 在 Okta 中，點選Applications (應用程式)標籤
- 搜尋 Asana
- 複製用於兩步驗證的登入 URL 以及 X.509 憑證
- 在此處深入瞭解。
OneLogin
- 在 OneLogin 中，前往「應用程式」>「尋找應用程式」
- 搜尋 Asana
- 點選Asana 旁的新增
- 點選Continue (繼續)
- 複製用於兩步驗證的 sign-in page URL (登入頁面 URL) 以及 X.509 Certificate (X.509 憑證)
SecureAuth
參閱此文章，瞭解使用 SecureAuth 設定 SAML for Asana 的逐步說明。
Entrust Identity
參閱此文章，瞭解如何使用 Entrust Identity 設定 SAML for Asana。
第 2 步：設定 Asana
使用您的身分提供商設定 Asana 後，您需要在 Asana 中進行適當的變更。
若要將組織變更為使用 SAML
- 點選您的個人資料照片，在下拉式功能表中選擇系統管理主控台
- 前往安全性標籤頁
- 前往全域驗證設定區段
- 點選SAML 驗證
- 按一下「除訪客帳戶外，對所有成員均為必要」
- 將您從第一步複製的登入頁面 URL 貼上到其對應的欄位中
- 將您從第一步複製的 X.509 憑證貼上到對應的欄位中
- 為您的成員設定工作階段逾時
- 如有需要，新增行動裝置工作階段逾時
- 點選 儲存變更
- 您的所有使用者將被登出 (包括您在內)，以確保您的所有正式成員從那一刻起透過 SAML 進行身份驗證。
若您使用開放原始碼或非本機整合，例如 Shibboleth 或 PingFederate。您需要與技術聯絡人共用 Asana SSO 中繼資料，以便在他們選擇的 IdP 中進行設定。
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID=" https://app.asana.com/ "> <md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location=" https://app.asana.com/-/saml/consume " index="0"/> </md:SPSSODescriptor></md:EntityDescriptor>我們建議您組織的超級管理員首先將 SAML 設定為選擇性，並且嘗試以其 SAML 認證登入。成功登入後，超級管理員可以將設定切換為必要。
妥善設定完成後，隸屬於您公司組織中的所有人，都需要使用您組織的身份識別提供者登入其 Asana 帳戶 (無論他們的帳戶是否有權存取其他組織或工作空間)。
超級管理員可以只將 SAML 登入指派給特定的使用者群組，藉此控制哪些內部使用者可以透過其身份識別提供者存取 Asana。若您是超級管理員，且在為您的組織設定 SAML 時遇到問題，請聯絡我們。若您想為不同的 IdP 使用者群組設定一些規則，請聯絡我們。
失敗的 SAML 登入的稽核記錄詳細資料
如果您的組織有權存取稽核紀錄 API，失敗的 SAML 登入嘗試會在稽核紀錄中產生user_login_failed事件。
當成員的 SAML 登入失敗時，這些user_login_failed事件現在包含由您的身分識別提供者傳回的 SAML 回應的消毒版本。這些額外的詳細資料可協助系統管理員和 IT 團隊瞭解登入失敗的原因，並快速識別 Asana 與身分提供商之間的設定問題，同時保留敏感值。
您可以使用稽核紀錄將失敗的登入嘗試與使用者、嘗試時間以及來自 Asana 和您的身分識別提供者的其他事件詳細資料相關聯。如需已完成的事件架構和欄位定義，請參閱稽核記錄事件開發人員文件。
SAML 工作階段逾時
超級管理員可在系統管理主控台中將 SAML 工作階段逾時設定在 1 小時與 30 天之間。特定逾時設定後，成員將自動登出，並且需要再次登入。
行動裝置工作階段逾時預設為停用。在視窗底部的行動裝置工作階段逾時區段中管理此設定。
公開憑證
Asana 支援 SAML 的 HTTP POST 綁定方法，而非 HTTP REDIRECT。這意味著您必須將您的 IdP 設定為使用 HTTP POST 綁定，以確保在驗證過程中安全地傳輸資料。
為了增強安全性，Asana 要求簽署 SAML 斷言或整個 SAML 回應。此措施可確保交換資料的真實性和完整性。請確保您的組態中至少有一個元素已簽署。
Asana 不會簽署 SAML 請求。因此，在您的 IdP 中設定 SAML 時，您應停用驗證請求的簽章。您可以將 Sign AuthnRequest 偏好設定設為 false (例如 AuthnRequestsSigned="false")。
請在 SAML 斷言中包含 IdP 簽署金鑰資訊。此金鑰對於驗證簽章和維護 SAML 斷言的安全性至關重要。
雙因素驗證
如欲深入瞭解雙因素驗證，請參閱此文章。
This article has been AI-translated.
Send translation feedback.