What is Custom Authentication: Header and Attributes?

When users access an Atlassian application the browser sends an HTTP request to the application. That HTTP request contains HTTP header values, which provide the Atlassian application with information about the request. During the handling of the request inside the Atlassian application custom code may process header values and additionally set request attribute values.

Often SSO-related headers are set by reverse proxies or VPN appliances or mobile gateways, where this trusted external entity does the real authentication and merely passes the identity to the Atlassian application.

Custom Authentication allows EasySSO to detect and act on the presence of specific headers or attributes in the request.

You can configure EasySSO to search for the presence of a certain header or attribute and, if they are present, take one or both of the following actions:

  1. Disable NTLM/Kerberos authenticator for this request
  2. Read the value of the header/attribute and use this information as the username to sign the user onto the Atlassian application. 

You can combine the two actions and configure EasySSO Custom Authentication to:

  1. Search for a header called "user" and if this header is found disable the NTLM/Kerberos authentication, and 
  2. take the value of the "user" header and use this value to authenticate the request and sign the user on. 

Headers Use Case

When you have an intermediary such as a proxy between Jira Software (for example) and your user, instead of Jira Software redirecting to the login page to prompt for login with username/password, EasySSO with Headers can take the user's identity (which the proxy has already established) and use that instead. As long as the proxy can add the Jira Software username to an HTTP header on the request, EasySSO can be configured to authenticate with that username in place of the login screen or attempting to use another SSO type.

Attributes Use Case

EasySSO can do the same thing with attributes. In this case the intermediary doesn't sit between the user and JIRA but rather inside JIRA itself, for example another plugin which does authentication or processes the headers. This plugin can add an attribute to an HTTP request, which EasySSO can use to authenticate a user.

You can combine header-based and attribute-based rules and configure EasySSO Custom Authentication to:

  1. Search for a header called "user" and if this header is found disable the NTLM/Kerberos authentication, and 
  2. take the value of the "user" attributed and use this value to authenticate the request and sign the user on, on assumption that custom code will take the header value, pre-process it to extract the username and set that as a value of the attribute

EasySSO articles


Purchase from the Atlassian Marketplace

EasySSO for JIRA, Confluence, Bamboo, Bitbucket and Fisheye/Crucible

Purchase