Security is always an important consideration when designing your application architecture. One of the most common approaches to securing your data is through SSO (Single Sign-On), which allows users to authenticate once and then gain access to all the related applications without having to login again for each one. It’s possible to configure a Single Sign-On flow with an AWS Application Load Balance in order to securely connect Jira and Confluence on premise. The result is an easier user experience while at the same time having better security than a traditional SSO infrastructure.
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.
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.
If you’re already hosting your Atlassian applications in AWS, handling authentication with the Application Load Balancer is an interesting option. Indeed, the ALB works like a firewall that protects your Atlassian applications from unauthenticated traffic.
Authentication is far from being frictionless for the user:
That’s where our app comes in. With AWS ALB Amazon Authentication, the resolution app, users don’t have to authenticate a second time when they are redirected to the Atlassian application.
But there are many other advantages:
Provision and deprovision users! Since its second version, the AWS ALB app ships with a User Synchronization module. This allows to create connectors that synchronize your local Jira or Confluence user directory with your cloud user directory. Your users will always be up to date and your admins will never have to go into Jira to create a new account or deactivate an existing one!
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!
Let’s have a closer look at how the app fits into the picture.
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.
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:
Let’s see how to configure the app to handle users. We’ll first look at how to set up user authentication. Next, we’ll have a look at the different options for user provisioning and deprovisioning.
In this guide, we’re assuming that you have successfully hosted your Atlassian Server or Data Center applications in an AWS server and that you have an ALB or ELB in your Amazon infrastructure.
Configuring the connection of the ALB with your IdP is quite simple. You will always need to follow the same three steps, although the details will change a bit from vendor to vendor.
Here’s a list of the specific guides:
Step 1. Select your IdP
It all starts with selecting the Identity Provider where your user directory is stored. If you have something other than Cognito, Azure, Okta or GSuite, just select Other.
Step 2. Configure how the tokens will be processed
In this step, you need to tell the app where to look in the JWT that the ALB will exchange whenever a user tries to login. The screenshot shows the most common setup.
Token Header Name: What’s the name of the token header that contains the user info?
Username Claim: Which field contains the username?
Step 3. Security checks
To ensure that the JWTs are not forged, you can have the app check the identity of the issuing IdP and your specific ALB.
To check the URL of the issuer, access your IdP as instructed in the corresponding guide (check the link at the start of this section)
There are two patterns for provisioning users with our AWS ALB Authentication app:
The two methods can perfectly coexist. For example, you can decide to update users as they login to grant them correct permissions to their Jira projects and Confluence spaces. But you can also synchronize the directory every night to ensure that you don’t have discrepancies in who should have an Atlassian account.
When in doubt, remember the major differences:
In this case, you will build an IdP connector to sync the entire directory.
Don’t be scared! This doesn’t mean that everyone in the company must get an account. You can filter by groups, and the most usual way is to only provision users who are assigned to Jira/Confluence in the IdP.
The steps for building the connector vary a lot from IdP to IdP, so we’ll just point you to the specific guides:
Also, bear in mind that these connectors are needed for the individual update using the REST API connection.
Once you’ve setup the connection, you can decide whether you want to:
If you choose to update users as they login, you can still choose between two different methods in the configuration.
The first method can be enough for simple needs, and is easier to setup. The second will satisfy even the most demanding use cases with dozens of user attributes.
In both cases, you need to enable User Provisioning with User Sync. To do that, scroll to User Provisioning Settings and enable the toggle as shown below:
Update During Login with a Just in Time Connector
For more details, here’s the step-by-step guide: Just-In-Time Provisioning – AWS ALB & Amazon Cognito Authentication
Update During Login with an IdP Connector
Using an existing connector for your IdP, you can also activate a lookup function that triggers whenever a user tries to login.
What you have to do is instruct the connector to look the user up with a specific attribute:
Now follow these steps In the User Provisioning Settings of the AWS ALB & Amazon Cognito Authentication app:
Here’s the step-by-step guide: User Provisioning with UserSync – AWS ALB & Amazon Cognito Authentication
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.