AMA: Cloud Identity & Security with Dave Meyer, Group Product Manager

[Dave Meyer]

Update: That's a wrap! Thanks so much for your questions. If you didn't make it for the live AMA, not to worry. Add your questions below and I will get to them ASAP. 

Hello Atlassian Community,

My name is Dave Meyer and I’m a Group Product Manager for Atlassian Access, our product for security and centralized administration across all your Atlassian cloud products, including features like SAML single sign-on (SSO), user provisioning and lifecycle management, user management at scale, and more.

On Tuesday, September 17th at 12 pm Pacific, I'll be hosting a real-time AMA to answer all your questions about identity in the cloud, including identity providers, governance, and IAM (identity and access management) more broadly. There are no dumb questions!

Cloud and security can be complex, and this space is constantly changing. We are here to help and give guidance wherever possible.

Here's how it works:

Add your questions below any time before or during the AMA. Be sure to take a look at other community member’s questions and up-vote those that you find interesting.

At 12 pm PST on Tuesday, Sep. 17th you can expect to see answers from me and my team rolling in. Watch the page and be ready to add follow-up questions and discuss further with other Community members. We'll wrap the event at 1 pm PST, but will be sure to answer any questions we didn't get to.

Cheers,

Dave

[Sam Caldwell · Accepted solution]

Has Atlassian considered using TLS certificate authentication to create a 'virtual perimeter' between Atlassian Cloud and customer devices?  This would go a long way to building trust in cloud services and could set Atlassian apart as a leader in cloud-based services unlike any other.  

I, for one, would sleep better at night knowing only authorized devices could connect to my Atlassian account services--in addition to user/pass and 2FA.

[Dave Meyer]

Great question @Sam Caldwell. We have considered TLS certificates and may go down this route in the future. We’re following a “walk before you run approach”:

1. Support a network-based perimeter based on IP addresses. This is commonly known as IP whitelisting. We already support this for Bitbucket Cloud and we have started working on this for Jira and Confluence Cloud. We’re expecting this to be available in early 2020. We will share an update on CLOUD-2636 soon.

2. Give admins better visibility into the devices users are using to connect to Atlassian products. We will start by showing organization admins all the devices each of their managed accounts has used. This will set us up to introduce some lightweight controls like limits on the number of devices or revoking sessions on certain risky devices.

We will continue to listen to customer requirements here and if it seems like we need to go farther and TLS certificates are the next logical step, it’s absolutely on the table.

[Andy - PTC Redundant]

Dave,

Since the last major Cloud Security AMA (with Adrian) back in May, what is/are the most important update(s) to security that us Cloud Admins must be aware of? 

[Dave Meyer]

Hey @Andy - PTC Redundant,

The most important update is around encryption. We now offer encryption at rest and in transit for our cloud products. Data drives on servers holding customer data and attachments in Jira Software Cloud, Jira Service Desk Cloud, Jira Core Cloud, Confluence Cloud, Statuspage, OpsGenie, and Trello use full disk, industry-standard AES-256 encryption at rest. However, it’s important to keep in mind that customer data on Bitbucket Cloud is not fully encrypted at rest. For more information about our encryption, see the Security Practices page on the Atlassian Trust Center.

We’ve also recently launched several updates for Atlassian Access including:

• New integrations with with Google Cloud Identity and Microsoft Active Directory Federation Services (ADFS): You can now integrate Atlassian cloud products with Microsoft ADFS for SSO and Google Cloud Identity for SSO and user provisioning.

• Increased transparency with our audit log: With the new cross-product audit log in Atlassian Access, you can now investigate processes, ensure accountability, and stay in compliance with company and third-party policies.

Finally, we launched new privacy settings that allow you to decide what personal information is visible across Atlassian cloud products and public communities, such as the Atlassian Community and the Developer Community. Read more here!

Cheers! Let me know if you have any questions about these updates.

Dave

[Jarek Krochmalski]

Is there a way to synchronize Atlassian Cloud users (Jira, Confluence) with Azure AD without actually buying the Access subscription? 

[Dave Meyer]

Hi @Jarek Krochmalski

Fair question. Currently user provisioning and group sync from external identity providers such as Azure AD requires an Access subscription. Our syncing is based on Atlassian’s implementation of the SCIM protocol. This API and the integrations that identity providers have built with it are only available with a subscription to Atlassian Access. We’ve worked hard to ensure that Atlassian Access is extremely competitively priced relative to other similar software.

Check out the Atlassian Access pricing page for more details.

Regards,

Dave

[Keri Miriello]

What are best practices for using Crowd and Atlassian Access together? Can we use both Access and Crowd for our Atlassian products? 

[Dave Meyer]

Great question @Keri Miriello !

We've designed identity and user management in Atlassian cloud products with native cloud standards top of mind. Since Crowd was designed for on-premises software, it's not available for our cloud products.

Crowd provides single sign on across multiple Atlassian server products. With Atlassian cloud products, users can use their Atlassian account across all our products and service for free.

Crowd also provides the ability to set up an external directory via LDAP, and Crowd Data Center offers support for SAML SSO. In the cloud, the functional equivalents of these features are SAML SSO and user provisioning via a subscription to Atlassian Access.

With our cloud products, you can create an organization and verify your domains, which will give you a centralized view of all users at your company, across all our products. From there, you can subscribe to Atlassian Access to configure SAML SSO with an identity provider like Okta, Azure AD, Active Directory Federated services, Google Cloud, or more.

User provisioning allows you to sync users and groups from those identity providers to your Atlassian cloud products. If you're using an on-premises LDAP directory or Active Directory, all of our supported identity providers offer connectors to those local directories.

There are a few fundamental differences to understand between deployments:

• For server, Crowd Server can act as your remote directory (similar to AD) and allows you to provide SAML SSO across multiple Atlassian server products.

• For Data Center, Crowd Data Center can also act as your remote directly (similar to AD). You can use Crowd's SAML SSO or connect your Data Center products directly to an external IdP.

• For cloud, users will utilize their Atlassian account to log in to all cloud apps. You can then connect Atlassian accounts to an external IdP with SAML SSO and user provisioning (SCIM) via a subscription to Atlassian Access.

Learn more about Atlassian Access and review the Atlassian Access for Cloud FAQ’s for additional detailed information.

Cheers,

Dave

[Deleted user]

Is there a way to (without using a paid plugin which doesn't work for the cloud anyway) to use Confluence together with BitBucket? Same Team, same Admin, centralized User-Administration-Interface? (Is the Answer Atlassian Access?) Why is an administrative Interface across many cloud instances belonging to the same company an extra paid feature? Should this not be the standard? So many questions..

[Dave Meyer]

Hi @[deleted],

That’s a very fair question. Frankly, we’re not where we would like to be in terms of user management across all our cloud products.

Just to be clear, we support a number of free capabilities today: any admin can create an organization and verify a domain. This gives you visibility into who has an account at your company, what products the user is using (including Bitbucket), and the ability to deactivate and delete the account. This includes All at no added cost.

On top of this, an Atlassian Access subscription offers more powerful security features like SAML SSO and user provisioning.

That said, we hear tons of customer around the ability to have a single view of all users in all your products so you can share groups between products, manage access in one place, etc. I can confirm that we’re actively working on this fairly soon. These basic administration capabilities like product access and groups will not come with any added cost.

Regards,

Dave

[Chris_Naurois]

Hi Dave,

Do you plan on letting customer portal only users to authenticate against the Service Desk Cloud REST API?

We have replicated the customer portal in our own app, since Jira powers a lot of our process. But our customers are not registered against an atlassian ID, just portal users.

Therefore, our apps cannot use the API to comment on their behalf or do much really - It would be interesting to know what your recommendation is for this fringe case :)

Many thanks in advance,

Chris

[Dave Meyer]

Hi @Chris_Naurois!

That’s a tough one. The answer is probably not in the short term – we’ve worked hard on supporting user impersonation for Atlassian Connect apps and 3-legged OAuth (3LO) for Jira, however these implementations are tightly tied to Atlassian accounts. In all honesty, I don’t think we’ve seen enough demand to justify the investing in supporting this. I think it’s totally valid, just a tough decision about what our Jira Service Desk, Identity, and Ecosystem teams can invest in that will have the most customer impact.

We have some big investments planned for extensibility across our cloud platform though, stay tuned.

[Chris Johnson]

Is there any potential for Atlassian Access to have support for niche self-hosted-only apps like Fisheye?

[Deleted user]

Edit

[Dave Meyer]

Never say never @Chris Johnson 🙂

Realistically, Atlassian Access was designed from the ground up on top of Atlassian’s global identity system of Atlassian accounts. For the Data Center editions of our products (Jira Software, Jira Service Desk, Confluence, Bitbucket, Crowd) that support SAML SSO, we’ve discussed potentially supporting the ability to long into these apps with a (cloud) Atlassian account, but we don’t have a timeline on this and it likely wouldn’t qualify as full Atlassian Access support.