Jira Align SSO support

Jira Align supports Security Assertion Markup Language (SAML) 2.0 Identity Provider-initiated single sign-on (SSO).

About SAML 2.0
Security Assertion Markup Language 2.0 is a version of the SAML standard for exchanging authentication and authorization data between security domains. SAML 2.0 is an XML-based protocol that uses security tokens containing assertions to pass information about a principal (usually an end user) between a SAML authority, that is, an identity provider, and a SAML consumer, that is, a service provider. SAML 2.0 enables web-based authentication and authorization scenarios including cross-domain SSO, which helps reduce the administrative overhead of distributing multiple authentication tokens to the user. You can find more information about SAML 2.0 here and here.

About SSO
Single sign-on is a property of access control of multiple related but independent software systems. With this property, a user logs in with a single ID and password to gain access to a connected system or systems without using different user names or passwords, or in some configurations, seamlessly sign on at each system. You can find more information about SSO here.

SAML and SSO in Jira Align
Jira Align supports SAML 2.0 Identity Provider-initiated SSO. We support multiple Identity Providers, each one is configurable in the Jira Align product through a unique SAML 2.0 Metadata XML. Each Identity Provider's Metadata should contain the certificates required for the Jira Align product to verify SAML XML signatures. In Jira Align, the SAML integration uses the RSA-SHA256 (https://www.w3.org/2001/04/xmldsig-more#rsa-sha256) signing algorithm.

Each Identity Provider can specify the Jira Align user lookup field which will be used to find Jira Align users from the SAML NameID value. Jira Align supports two user lookup fields: the email address and External ID of a Jira Align user. The product requires signing both the SAML response and the assertion. SAML encryption is not supported, as our application requires all traffic over an HTTPS/SSL encrypted
protocol. Jira Align does not have a single specific endpoint URL that handles SSO requests, as any page (URL) in the product can be directly authenticated into. However, most customers' Identity Providers are configured to use a default page URL, for example, https://CUSTOMERNAME.jiraalign.com.

Jira Align can be configured to allow manual login when SSO is enabled or to not allow manual login when SSO is enabled. If manual login is not enabled with SSO, Jira Align typically requires the ability to authenticate using the customers' Identity Provider so that members of the Jira Align team can assist customers with successful use of Jira Align.

You can use your company's internal Identity Provider to authenticate into the Jira Align product. Contact your company’s Identity Provider administrator to get the SAML 2.0 Metadata to add to Jira Align and to set up your company’s Identity Provider for Jira Align.

For identity providers such as PingFederate (versions below 9.1) and OneLogin, it is possible to sign both the response and assertion, but only when encrypting assertions. Jira Align doesn’t support encrypting assertions, so signature should be disabled via SQL command directly on the box.

Sample IdP metadata

Below is a simplified metadata file sample. Your version may vary depending on your IdP:

<EntityDescriptor ID="%IDP unique identifier%" entityID="%IDP entity ID here%" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
    <IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
        <KeyDescriptor use="signing">
            <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
                <X509Data>
                    <X509Certificate>%IDP signing cert here%</X509Certificate>
                </X509Data>
            </KeyInfo>
        </KeyDescriptor>
    </IDPSSODescriptor>
</EntityDescriptor> 

SAML Assertion Condition
Jira Align validates the SAML Assertion Condition time range. The valid range should be a small amount of time before the current time for the NotBefore attribute and a small amount of time after the current time for the NotOnOrAfter attribute. With typical clock variances and drift for servers across the Internet, a couple minutes on each side of the current time is usually sufficient.

We found that some Identity Providers cannot set the NotBefore attribute to a value other than the current time. This typically causes the SAML Assertion to be invalid due to clock time differences between the Identity Provider and Jira Align servers.

To help the customers without the ability to manage the NotBefore attribute's time, the Jira Align product will automatically skew the NotBefore time to be the same difference from the current time, as the NotOnOrAfter time is different from the current time. For example, if the current time and the NotBefore time are both the same, and if the NotOnOrAfter time is 2 minutes different from the current time, then Jira Align will automatically skew the NotBefore time to be 2 minutes before the current time to create a time span that can accommodate click variances and drift for servers connecting across the Internet.

Transitioning an Identity Provider to a new signing certificate

The SAML 2.0 specification allows for the Identity Provider’s metadata to contain two signing certificates concurrently. The Identity Provider should be configured for a new signing certificate ahead of the existing signing certificate expiration or transition. The Identity Provider is not expected to start using this newly configured signing, though the new Identity Provider’s metadata should be generated so it includes both signing certificates and updated within the SSO configuration section of Jira Align (the service provider). Once these two tasks are completed, the Identity Provider can be scheduled to transition to start using the newly configured signing certificate at a specified date. The specification is designed this way to avoid any downtime by providing the ability to configure all service providers ahead of the Identity Providers transition to use a new signing certificate.