Atlassian Acces + Azure SSO / Conditional Access with named locations

[Jonny Klaas]

Hey there, 

we recently setup Atlassian Access with our Azure AD to secure our logins. 

In the next step we want to use "conditional access" to enforce the use of VPN and specific public IPs. I've setup a rule and the login will be blocked if I connect from a foreign IP address.All fine. But if I disconnect the VPN from a valid session the login at Jira still persists? All other Apps like Google Gsuite noticed very fast, that the conditional requirements are now missing. 

So is this behavior intended or just a bug? when will the user be kicked out from the session? The general logout time would be way too long

Regards,

Jonny

[Ramon M]

Hey Jonny, 

Thanks for using Atlassian Community. 

The SSO solution provided by Atlassian Access is actually implemented with SAML. The communication between Azure and Atlassian cloud happens at the time of the user's authentication. On a user's successful login, Azure will send a SAML message to Atlassian. To action that message, our ID service will generate the session of the user on Atlassian cloud. 

What you noticed is expected. There are 2 sessions involved in that login flow, one in Azure environment and one for Atlassian cloud. Invalidating the session in Azure will not affect the session in Atlassian cloud. On Atlassian side, there are set defined days for the session duration and Atlassian Access allows you to control that for your managed accounts users via the Session Duration configuration. 

Just to let you know as well that we do not have that conditional access yet for Jira and Confluence in Atlassian cloud but there is an existing feature request on CLOUD-2636 that is already under consideration with our product team. 

I hope this information helps. 

Regards,
Ramon

[Jonny Klaas]

Hey Ramon, 

Thanks for your reply and the explanation. Yes the Session Duration could be reduced as one option, but this is not a "safe" way to enforce conditional access rules from Azure AD. It's also a global option and we can't enforce it to selected user groups. 

Maybe you could think about to integrate the session at Atlassian with the Azure AD Session. As an example If I click the logout button at our Google GSuite, I will logged out from my whole Azure AD Session. It's a really nice feature and the Gsuite noticed instantly if the conditional rules from the Azure AD are violated.

Don't get me wrong but you offer an extra product (Atlassian Access), which we have to pay for and which is also basic requirement to integrate with Azure AD.  But now the conditional rules at Azure AD are useless because there are different sessions for the users? 

The whole SSO process are bypassed except at the login window. 

Could you understand the problem? *scratch head*

The linked feature request is also only a workaround for the problem. Yes we can set trusted IP locations but other rules from the Azure AD will be ignored.

Regards,

Jonny

[Dave Meyer]

Hi @Jonny Klaas , 

Jira and Confluence are featured apps for Microsoft Conditional App Access Control. Did you follow the instructions here? https://docs.microsoft.com/en-us/cloud-app-security/proxy-deployment-aad#portal

If so, we can review this with our partners at Microsoft to understand what's going wrong. I agree with @Ramon Macalinao that setting up a shorter idle session duration policy is the best short term approach.

With regard to the Atlassian Access subscription, we offer Atlassian Access as a standalone offering in order to bring features like SSO and user provisioning to our products at a much cheaper price than other SaaS applications. We believe that the per user price of any one of our cloud products with Atlassian Access is extremely competitive, and if a user is using multiple products or tenants, you are still only billed once for Atlassian Access, so it becomes an even better value. We have some price comparisons on our website here: https://www.atlassian.com/software/access/pricing

Cheers,

Dave

[Nicholas Molina]

I wanted to follow up on this as we have a similar issue. It seems like we need to continue using an Atlassian Premium subscription to keep the IP Whitelist enforced otherwise the user can authenticate in-network using Azure AD then disconnect from our VPN and the Atlassian session continues even though it fails the Azure Conditional Access IP Whitelist policy. 

Any updates?

Thanks,

Nick

[Dave Meyer]

@Nicholas Molina your understanding is correct. As mentioned you can mitigate this risk through session duration controls (or using device management software, but this isn't my area of expertise). But IP allowlisting via the Premium plan is the easiest way to comprehensively assure there is no non-VPN access.