Here at Cloudflare, we rely on a set of productivity tools built by Atlassian, including Jira and Confluence. We secure them with Cloudflare Access. In the past, when our team members wanted to reach those applications, they first logged in with our identity provider credentials to pass Access. They then broke out a second set of credentials, specific to Atlassian tools, to reach Jira. The flow is inconvenient on a desktop and downright painful on a mobile device.
While Access can determine who should be able to reach an application, the product alone cannot decide what the user should be able to do once they arrive at the destination. The application sets those specific permissions, typically by requiring another set of user credentials. The extra step slows down and frustrates end users. Access saves time by replacing a cumbersome VPN login. However, we wanted to also solve the SSO problem for our team.
We created a plugin, specific to Atlassian, that could take identity data from the token generated by Access and map it to a user account. Our team members log in with our identity provider to pass Access, and then Access could set their user permissions in Jira or Confluence. No extra credentials required.
We’re excited to announce that we are sharing the same SSO plugin that we use every day at Cloudflare so that all Access customers can deploy it for their hosted Atlassian tools. You can add this plugin immediately to your Atlassian instance and remove that extra credential requirement. Like we did at Cloudflare, you can make the day more convenient for everyone in your team.
We aren’t stopping with Atlassian. We’re working with partners to expand JWT-based authentication. If you’re building or maintaining a product with an authorization flow, we want to help you add this functionality.
What is a JWT and how does Access use them?
JSON Web Tokens (JWTs) allow systems to communicate stateless data, or claims, in a secure format. The tokens follow a standard established in RFC 7519. That open standard allows different groups to send secure, encrypted data in a format that both sides can create and understand. Each JWT consists of three Base64-URL strings: the header, the payload, and the signature.
The header defines the cryptographic operation that encrypts the data in the JWT.
The payload consists of name-value pairs for at least one and typically multiple claims, encoded in JSON. For example, the payload can contain the identity of a user
The signature allows the receiving party to confirm that the payload is authentic.
Cloudflare Access relies on JSON Web Tokens to confirm identity before allowing or denying access to sensitive resources. When your end user reaches an application protected by Access, they first sign in with your identity provider. We communicate with that provider through OAUTH or SAML flows to verify the user identity. Once confirmed, we create a JWT by using the RS256 algorithm, add data to the payload, and sign the token with a public private key pair.
The token we issue stores:
User identity: typically the email address of the user retrieved from your identity provider.
Authentication domain: the domain that signs the token. For Access, we use “example.cloudflareaccess.com” where “example” is a subdomain you can configure.
Audience: The domain of the application you are attempting to reach.
Expiration: the time at which the token is no longer valid for use.
When a request is made to an application behind Access, Cloudflare looks for the presence of that token. If available, we decrypt it, validate its authenticity, and then read the payload. If the payload contains information about a user who should be able to reach the application, we let them through. Applications can make use of the same validation step to set permissions specific to a user. You just need to associate the user in the JWT with a user in your application, which is a problem a new module, or plugin, can solve.
Sharing our Atlassian plugin
We selected Atlassian because nearly every member of our global team uses the product each day. Saving the time to input a second set of credentials, daily, has real impact. Additionally, removing the extra step makes reaching these core tools easier from mobile devices.
The Java plugin is built on top of the Atlassian Plugin SDK. When requests are made to pages within your Atlassian deployment, Atlassian will redirect to the login page. With the plugin is installed, that login page will first look for the presence of the token issued by Cloudflare Access. If present, the plugin will make sure the token is valid and parse the user info in the payload.
Next, the plugin attempts to map the email address in the payload to an email address of a user in your Atlassian account. If an account is found, the plugin will initiate a user session for that specific user. The plugin relies on the email or username in your identity provider matching the email configured in Atlassian.
When we rolled this out at Cloudflare, team members had one fewer disruption in their day. We all became accustomed to it. We only received real feedback when we disabled it, briefly, to test a new release. And that response was loud. When we returned momentarily to the old world of multiple login flows, we started to appreciate just how convenient SSO is for a team. The lesson motivated us to make this available, quickly, to our customers.
We are making the code public for this tool, instead of releasing it as a wrapped plugin in the marketplace, so that you can review the implementation yourself. Install it on your deployment today; you can find instructions here. From our own experience, we think your end users are going to love removing that extra login step.
Expanding JWT-based authorization
Atlassian tools are popular, but solving this problem for Jira and Wiki is just the beginning. Each member of your team probably uses a dozen or more internal applications each day. Different groups within your organization also rely on different sets of tools.
We’re working with projects to expand support for JWT-based SSO. One example is Redash, a popular data query and visualization tool. In the last week, Redash added the functionality to their product. Unlike the Atlassian plugin, the change only required the addition of a new option within the tool’s authentication flow. When enabled, the new feature checks for the presence of a JWT in the request. If valid, Redash will map the identity in the payload to a user profile and start a session with those permissions. The end user logs in once, at the Access screen, and arrives at their unique Redash account.
If you’re interested in improving the SSO flow for your product, please reach out through the form here and we can provide input and best practices on implementation. Feel free to use the Atlassian and Redash examples as templates. We’re excited to work with you to remove redundant steps for your users.