Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Atlassian Acces + Azure SSO / Conditional Access with named locations


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



2 answers

1 vote
Ramon M
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Nov 20, 2019

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. 


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.




Dave Meyer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Nov 25, 2019

Hi @Jonny Klaas , 

Jira and Confluence are featured apps for Microsoft Conditional App Access Control. Did you follow the instructions here?

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:



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?



Dave Meyer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Aug 03, 2020

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

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events