Authentication and access management options for paid plans

By default, Asana's regular authentication steps apply, and your organization members have the choice to either use a traditional password or Google SSO to log into their respective accounts.

In paid organizations, super admins can select how their members log into Asana, set password complexity requirements and force reset all members' passwords. If you purchase a division plan on Enterprise, Enterprise+, then SAML can also be enabled. SAML can also be enabled for divisions on the Legacy Enterprise tier.

Paid authentication settings only apply to your organization members. Organization guests are not affected by your authentication settings.

Password strength and force password reset

Super admins have the option to force reset passwords for all members in the organization, and set a strength level requirement for passwords.

To manage password complexity and reset passwords

1. Click your profile photo and select admin console
2. Navigate to the Security tab
3. Select the Password strength tab to choose between strong and simple password strengths
4. Choose Password reset to force reset all passwords

When you force reset passwords for your organization, members will be prompted to reset their password upon their next log in. Members already logged into their Asana account will be force logged out and will need to reset their password.

Password strength

You can choose your password strength by clicking into the Security tab of your admin console and clicking on Password strength.

You can choose between two password settings; Simple or Strong. Super admins of Enterprise+ and Legacy Enterprise organizations have a third Custom option.

Simple passwords must have at least 8 characters. Strong passwords must have at least 8 characters and must include characters from at least three of the following types: lowercase, uppercase, numbers, and special characters. 

Custom passwords allow you to customize the complexity of the password requirements of your domain.

Changing the password requirements option does not affect the passwords of existing users. The domain admin will have to force reset all user passwords in order for the new password requirements to apply to existing users.

Google Sign-In

If your company uses Google Workspace for business or education, and you are using a paid version of Asana, you have the option to require your members to authenticate via Google.

You can not set up Google Sign-In if you are on a Division Plan

To change your organization to Google Sign-In

1. Click your profile photo and select Admin console from the drop down menu
2. Navigate to the Security tab
3. Navigate to the Google Sign-in tab
4. Select the Members must log in with their Google Account

Once this change has been saved, any passwords associated with your members' Asana accounts will no longer work and they will be required to use Google SSO.

If you are changing the email domain associated with your Google accounts, please contact us so that we can add the new domain to your organization.

SAML

If your company uses an identity provider like OneLogin, Okta, LastPass, Azure AD, SecureAuth, or Active Directory, your IT department may want to configure SAML. To set up SAML, you must:

• Belong to an organization on Asana Enterprise, Enterprise+, or Legacy Enterprise
• Be a super admin the organization

Once an organization has been set up with SAML, the organization members will no longer need a password to log into their accounts. From the login page, they can just enter their email and click Log in, leaving the password field empty.

Step One: Configure your IDP

If you meet those conditions, the first step is to configure Asana with your identity provider. The steps for OneLogin, Okta, LastPass, Bitium, SecureAuth, Active Directory and Entrust Identity are listed below, but you can also do this for other identity providers:

Active Directory

Check out this document to find out how to set up SAML for Asana with Active Directory.  

You could also try Okta Cloud Connect. Okta Cloud Connect is a free edition of Okta for one application. It allows you to set up Okta for AD integration and SSO for one core application. You can find more information here.  

Azure AD

Check out this article to find out how to set up SAML for Asana with Azure AD.  

Google Workspace

Learn how to set up SSO via SAML for Asana here.  

LastPass

• In LastPass Enterprise, first go to your Enterprise Console and select the SAML tab at the top of the console. You will then be taken to the main SAML page
• Click the Asana app icon
• Follow the instructions on the screen
• Copy the Log-in URL and the x.509 certificate for use in Step Two

Okta

• In Okta, click the Applications tab
• Search for Asana
• Copy the Log-in URL and the x.509 certificate for use in Step Two
• Learn more here.  

OneLogin

• In OneLogin, go to Apps > Find apps
• Search for Asana
• Click add next to Asana
• Click Continue
• Copy the the sign-in page URL and x.509 certificate somewhere for use in Step Two

SecureAuth

Check out this article for step-by-step instructions on setting up SAML for Asana with SecureAuth.  

Entrust Identity

Check out this article to find out how to set up SAML for Asana with Entrust Identity.

Step Two: Configure Asana

After you've configured Asana with your identity provider, you now make the appropriate changes in Asana. 

To change your organization to SAML

1. Click your profile photo and select Admin console from the drop down menu
2. Navigate to the Security tab
3. Navigate to the SAML authentication tab
4. From the SAML options field click Required for all members, except guest accounts
5. Paste the sign-in page URL that you copied from Step One into its corresponding field
6. Paste the X.509 Certificate that you copied from Step One into its corresponding field
7. Set a session timeout for your members
8. Click the Save changes button

If you are using open-source or non native integrations, such as Shibboleth or PingFederate. You will need to share the Asana SSO metadata with the technical contact to be configured in their IdP of choice.

<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>

We recommend that a super admin for your organization first sets SAML to optional and tries to log in with their SAML credentials. Then after a successful login, the super admin can switch the configuration to required.

Once set up properly, anyone who belongs to your company's organization will be required to log in to their Asana account with your organization identity provider (regardless of other organizations or workspaces their account may have access to).

Super admins can control which internal users have access to Asana via their identity provider, by assigning SAML Sign-In to specific user groups only. If you are a super admin and are having trouble with setting up SAML for your organization, contact us. If you’re looking to set some rules for different IdP user groups, please contact us.

SAML session timeout

Super admins can set SAML session timeout between 1 hour and 30 days in the admin console. Members will be automatically logged out and asked to log in again after the specified timeout set.

Mobile session timeouts are disabled by default. Manage this setting in the Mobile session timeout section at the bottom of the window.

Public certificate

Asana supports the HTTP POST binding method for SAML, not HTTP REDIRECT. This means you must configure your IdP to use HTTP POST bindings, ensuring secure data transmission during the authentication process.

For enhanced security, Asana requires that either the SAML Assertions or the entire SAML Response is signed. This measure ensures the authenticity and integrity of the data exchanged. Ensure at least one of these elements is signed in your configuration.

Asana does not sign SAML requests. Consequently, when setting up SAML in your IdP, you should deactivate signing for authentication requests. This can be done by setting the Sign AuthnRequest preference to false (e.g., AuthnRequestsSigned="false").

Please include the IdP signing key information within the SAML assertion. This key is crucial for verifying the signature and maintaining the security of the SAML assertion.