기본적으로 Asana의 표준 인증 단계가 적용되며, 조직의 멤버는 기존 비밀번호 또는 Google SSO를 사용하여 계정에 로그인할 수 있습니다.
유료 조직에서 최고 관리자는 멤버가 Asana에 로그인하는 방식을 선택하고, 비밀번호 강도 요건을 설정하고, 모든 멤버의 비밀번호를 강제로 다시 설정할 수 있습니다. Enterprise, Enterprise+에서 디비전 플랜을 구매한 경우 SAML을 활성화할 수 있습니다. Legacy Enterprise 플랜의 디비전에서도 SAML을 활성화할 수 있습니다.
유료 인증 설정은 조직 멤버에게만 적용됩니다. 조직 게스트는 인증 설정의 영향을 받지 않습니다.
Asana의 기능이 마음에 드세요? Asana 무료 체험을 시작해 보세요. 무료로 체험하기.
비밀번호 보안 수준 요건을 업데이트하고 조직의 비밀번호를 강제로 재설정하는 방법을 알아보려면 이 문서를 확인하세요.
회사에서 비즈니스나 교육을 위해 Google 작업 공간을 사용하고 있으며 Asana 유료 버전을 사용하고 있다면 멤버에게 Google을 통해 인증할 것을 요구할 수 있습니다.
메모
디비전 플랜을 이용하고 있는 경우 Google 로그인을 설정할 수 없습니다.
조직을 Google 로그인으로 변경하려면 관리 콘솔의 보안 탭으로 이동합니다. 여기서 전역 인증 설정 으로 이동하여 Google 로그인 을 클릭합니다. 게스트를 제외한 모든 멤버에게 필수 를 선택하고 변경 사항 저장 을 클릭합니다.
변경 사항을 저장하면 멤버의 Asana 계정과 연결된 비밀번호가 비활성화되며 멤버는 Google SSO를 사용해야 합니다.
Google 계정에 연결된 이메일 도메인을 변경하려는 경우 Asana가 조직에 새로운 도메인을 추가할 수 있도록 지원팀에 문의해 주세요.
회사에서 OneLogin, Okta, LastPass, Azure AD, SecureAuth, Active Directory와 같은 ID 공급자(IdP)를 사용한다면 IT 부서에서 SAML을 구성할 수 있습니다. SAML을 구성하려면 다음 조건을 충족해야 합니다.
조직이 SAML을 설정하면 조직 멤버는 계정에 로그인하기 위해 더 이상 비밀번호를 사용하지 않아도 됩니다. 로그인 페이지에서 비밀번호 필드는 빈칸으로 남겨둔 채 이메일을 입력하고 로그인 을 클릭하기만 하면 됩니다. 또는 IdP 앱 대시보드를 사용하여 Asana에 액세스할 수도 있습니다.
위의 조건을 충족하는 경우, 첫 번째 단계는 IdP에서 Asana를 구성하는 것입니다. OneLogin, Okta, LastPass, Bitium, SecureAuth, Active Directory, Entrust Identity에서 설정하는 단계가 아래에 설명되어 있지만, 이 외의 IdP에서도 구성할 수 있습니다.
이 문서에서 Active Directory를 통해 Asana의 SAML을 설정하는 방법을 알아보세요.
Okta Cloud Connect를 이용할 수도 있습니다. Okta Cloud Connect는 하나의 애플리케이션에 사용할 수 있는 Okta의 무료 에디션입니다. 하나의 핵심 애플리케이션에 대해 Okta를 설정하여 AD 연동 및 SSO를 구현할 수 있습니다. 여기에서 자세한 정보를 확인하실 수 있습니다.
이 가이드에서 Azure AD를 통해 Asana의 SAML을 설정하는 방법을 알아보세요.
여기에서 Asana를 위한 SAML을 통해 SSO를 설정하는 방법을 알아보세요.
이 가이드에서 SecureAuth를 통해 Asana를 위한 SAML을 설정하는 단계별 지침을 알아보세요.
이 기사에서 Entrust Identity를 통해 Asana를 위한 SAML을 설정하는 방법을 알아보세요.
IdP에서 Asana를 구성한 뒤 Asana에서 필요한 설정을 합니다.
오픈 소스 연동을 사용하거나 자체적으로 제공하는 연동이 아닌 경우(예: Shibboleth, PingFederate) 선택한 IdP에서 구성하기 위해 기술 담당자와 Asana SSO 메타데이터를 공유해야 합니다.
<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 자격 증명으로 로그인할 것을 권합니다. 로그인에 성공한 뒤, 최고 관리자는 구성을 필수로 변경할 수 있습니다.
적절하게 설정하고 나면 회사의 조직에 속한 사용자는 조직 IdP를 통해 Asana 계정에 로그인해야 합니다(계정이 다른 조직이나 작업 공간에 속해있더라도 대상이 됩니다).
최고 관리자는 SAML 로그인을 특정 사용자 그룹에만 할당하여 IdP를 통해 Asana에 액세스할 수 있는 내부 사용자를 제어할 수 있습니다. 최고 관리자로서 조직의 SAML을 설정하는 데 어려움을 겪고 있다면 지원팀에 문의하세요. 다른 IdP 사용자 그룹에 대한 규칙을 설정하려면 Asana에 문의해 주세요.
조직이 감사 로그 API 에 액세스할 수 있는 경우, SAML 로그인 시도가 실패하면 감사 로그에 user_login_failed 이벤트가 생성됩니다.
멤버의 SAML 로그인이 실패하면 이제 이러한 user_login_failed 이벤트에 ID 공급자가 반환한 SAML 응답의 삭제된 버전이 포함됩니다. 이 추가 세부 정보는 관리자와 IT 팀이 로그인에 실패한 이유를 이해하고 민감한 값은 수정된 상태로 유지하면서 Asana와 ID 공급자 간의 구성 문제를 빠르게 식별하는 데 도움이 됩니다.
감사 로그를 사용하여 실패한 로그인 시도를 사용자, 시도 시간, Asana 및 ID 공급자의 기타 이벤트 세부 정보와 연관시킬 수 있습니다. 완료된 이벤트 스키마 및 필드 정의는 감사 로그 이벤트 개발자 문서 를 참조하세요.
최고 관리자는 관리 콘솔에서 SAML 세션 시간 초과를 1시간~30일 사이로 설정할 수 있습니다. 멤버는 자동으로 로그아웃된 후 설정된 시간 초과 후 다시 로그인할 것인지 묻습니다.
모바일 세션 시간 초과는 기본 설정으로 비활성화되어 있습니다. 창 하단의 모바일 세션 시간 초과 섹션에서 이 설정을 관리합니다.
Asana는 HTTP REDIRECT가 아닌 SAML에 대한 HTTP POST 바인딩 방법을 지원합니다. 즉, 인증 프로세스 중에 안전한 데이터 전송을 보장하기 위해 HTTP POST 바인딩을 사용하도록 IdP를 구성해야 합니다.
보안을 강화하기 위해 Asana는 SAML 어설션 또는 전체 SAML 응답에 서명해야 합니다. 이 조치는 교환된 데이터의 진위성과 무결성을 보장합니다. 구성에서 이러한 요소 중 하나 이상이 서명되었는지 확인하세요.
Asana는 SAML 요청에 서명하지 않습니다. 따라서 IdP에서 SAML을 설정할 때 인증 요청에 대한 서명을 비활성화해야 합니다. Sign AuthnRequest 기본 설정을 false(예: AuthnRequestsSigned="false")로 설정하여 이 작업을 수행할 수 있습니다.
SAML 어설션에 IdP 서명 키 정보를 포함하세요. 이 키는 서명을 확인하고 SAML 어설션의 보안을 유지하는 데 매우 중요합니다.
2단계 인증에 대한 자세한 내용은 이 가이드 를 참조하세요.
메모
이 기사는 AI로 번역되었습니다.
번역 피드백을 보내주세요.