Quick note about upcoming releases: The app will also be released soon for Bitbucket, and for Atlassian Data Center products specifically. For now, however, the apps can be installed and use in the Server version until the Data Center version is approved.
With ALB Authenticate, any organization already hosting its Atlassian applications in AWS can benefit from its existing cloud infrastructure to create an additional layer of security and generate a seamless user authentication flow.
The approach resembles very closely what can be obtained with a more traditional SAML SSO setup, with a few significant differences that will be covered in this article.
The role of AWS Application Load Balancers in your Atlassian Stack
This is not the place to focus on the differences between classic load balancers and application load balancers. However, before diving into the authentication features, let’s do a quick reminder on the role of Application Load Balancers for enterprise customers of AWS and in the Atlassian stack specifically.
The major role: distributing user traffic among available nodes
In Atlassian Data Center applications, a load balancer is placed to distribute users between the different nodes where the instance is installed. The load balancer routes traffic so that it never becomes a problem, usually relying on health checks and server diagnostics. This ensures that the application traffic doesn’t become an excessive stress, which typically happens during peaks of concurrent users, or when one or more of the nodes are down.
When Data Center applications are hosted in AWS, they are typically protected with an Application Load Balancer (ALB). With many interesting features, one worth mentioning is the possibility of sticky sessions that provide a more continuous experience to clients.
Using AWS Application Load Balancers and Amazon Cognito in your Jira authentication flow
Application Load Balancers can also be configured to authenticate users, usually in combination with Amazon Cognito identity pools or with cloud Identity Providers that support the OIDC protocol, such as Azure AD, Okta or GSuite.
Read the AWS documentation on How to authenticate users with an Application Load Balancer
Main advantages of AWS ALB Authentication
Here are the main reasons why you should consider this setup if you’re already hosting your Atlassian applications in AWS.
- An exceptional security layer. Use your Application Load Balancer as a firewall that protects your Atlassian applications from unauthenticated traffic.
- Create a seamless flow for your users. With the resolution app, users don’t have to authenticate a second time when they are redirected to the Atlassian application.
- Integrate with your existing cloud infrastructure. AWS ALB Authenthication fits perfectly if your company is already using OpenId Connect, Amazon Cognito, or any OIDC compliant Identity Provider.
- Easy configuration. Select which token and token claim should be used to authenthicate into Jira or Confluence. With predefined templates for Amazon Cognito, Okta, Azure, and GSuite!
But let’s have a closer look at how the app fits into the picture.
Basic flow with AWS ALB Authentication
- An unauthenticated user tries to access “jira.awesomedomain.com”, but doesn’t reach Jira.
- The AWS Application Load Balancer intercepts the incoming http request before it reaches the Atlassian application and redirects the user to the Identity Provider for authentication.
- After a successful authentication, the user is redirected back to the ALB along with an ID token which allows the ALB to obtain more user details.
- Resolution’s app sends the user and its info to the Atlassian application with an HTTP header. No additional login is required. That’s a good job, right?
Comparison with a SAML SSO authentication flow
Let’s now look at a SAML SSO flow from a very high level to understand the main differences between the alb authentication and a more traditional SSO solution.
- An unauthenticated user tries to access “jira.awesomedomain.com”, and hits the Atlassian login page
- The SAML SSO app redirects the user to the IdP login page
- The user authenticates on the IdP
- If the authentication is successful, the user is redirected back to Jira and directly logged in.
As you can see, the main difference is that in a SAML SSO authentication flow an unauthenticated user will always arrive at the Atlassian product in the first place. This has some implications:
- You have to trust the security of your Atlassian product. If there’s a loophole allowing unauthenticated access to the instance, an unauthenticated user could exploit it.
- Public pages in the Atlassian product will be accessible to anybody. And Jira has many of them (if you haven’t configured your SSO app to protect them).
- Higher traffic load on the Atlassian application. All unauthenticated traffic hits Jira or Confluence directly before the logging event. Instead, the Application Load Balancer intercepts the incoming traffic and only lets in legitimate users. In scenarios where scripts or attackers try to ddos your Atlassian application, they will “only” be able to hit the load balancer. Your Atlassian product will be left alone.
If you have successfully migrated your Atlassian instances to AWS, then AWS ALB Authentication is the easiest way to prioritize security and performance while maintaining a frictionless user authentication experience.
Have a try now for free for 30 days, and get in touch with our support team if you need any help figuring out the exact details of your implementation!