Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

What is the role of IOPLEX Jespa

IOPLEX Jespa library is the only pure java implementation of NTLMv2 based authenticator. EasySSO integrates Jespa with Atlassian applications (JIRA and Confluence), providing the glue between the library code and Atlassian application code. Jespa library does all heavy lifting behind the scenes to authenticate a user - performing NTLMv2 challenge to the client (i.e. browser) and communicating with the Domain Controller. Due to the licensing restrictions we are unable to simply package IOPLEX Jespa within EasySSO and a separate download from ioplex.com is required. The library distribution can then be uploaded via EasySSO and installed within your Atlassian product.

We use robust IOPLEX Jespa architecture and security provider framework in our Kerberos support too. DNS lookups, Domain Controller discovery, support for AD sites, automatic failover, anonymous browsing - these are just some of the features that Jespa gives us. Why roll your own if you can stand on the shoulders of the giants?

Will EasySSO work together with Atlassian Crowd

Yes, EasySSO performs authentication “before” the request reaches the core application (JIRA or Confluence). Once authentication has been performed and the user is identified, by IOPLEX Jespa library communicating with Domain Controller, the username is handed over the Application in the same way as the default authenticator does. Atlassian Crowd in this scenario plays a role of a back-end user directory and is not involved in the authentication process. Currently for external Crowd directories there is a limitation that the user must exist in the application already (i.e. synchronized) before EasySSO can perform auto-login. This limitation doesn't exist for LDAP-based directories e.g. Active Directory.

How is EasySSO different from Atlassian Crowd SSO

Atlassian Crowd provides single sign-on between Atlassian applications i.e. a user will still need to provide their credentials at least once via the usual login screen when accessing one of the applications. Once authenticated, access to other applications connected via Crowd SSO is possible without re-entering the credentials. Once the underlying token expires the user will need to re-authenticate.

On the contrary, EasySSO performs single sign-on between the user's Windows workstation and Atlassian application using information already provided when the user logged in into their workstation. No credentials are being asked and once the underlying session expires, the user is re-authenticated transparently with no additional actions required. In essence EasySSO provides "auto-login" functionality for Atlassian applications.

If the user navigates to another Atlassian application with EasySSO enabled - they will be automatically logged in there. Though this process is completely independent from the first application, to the user it seems that they are always logged in into all Atlassian applications.

How is EasySSO different from Active Directory/LDAP Integration

Integration with Active Directory/LDAP allows users of Atlassian applications to use the same credentials as they are using elsewhere in the organisation and most likely when logging in into their Windows workstations. However the user will still need to provide their credentials via the usual login screen when accessing Atlassian applications. Access to other application will require entering credentials again into that application login screen. Once the underlying cookie expires the user will need to re-authenticate.

On contrary, EasySSO performs single sign-on between the user's Windows workstation and Atlassian application using information already provided when the user logged in into their workstation. No credentials are being asked and once the underlying session expires, the user is re-authenticated transparently with no additional actions required. In essence EasySSO provides "auto-login" functionality for Atlassian applications.

If the user navigates to another Atlassian application with EasySSO enabled - they will be automatically logged in there. Though this process is completely independent from the first application, to the user it seems that they are always logged in into all Atlassian applications.

How is EasySSO different from Kerberos-based authenticators

Since late 2008 EasySSO has been using NTLMv2 protocol, which is similar to Kerberos in what it is trying to achieve, though different in how. In general NTLM is much more forgiving then Kerberos, it will work in all situations where Kerberos will and in many situations where Kerberos-based authentication is not possible, NTLMv2 will still work e.g. various extranet/VPN/firewall/mobile networks environments. In general NTLM is much easier to configure (hence EasySSO).

Since October 2015 EasySSO supports both NTLMv2 and Kerberos-based authentication. 

Isn't NTLM insecure

NTLM protocol has existed for many years and has several versions. Indeed NTLMv1 protocol is insecure and shouldn't be used as per Microsoft recommendations.

EasySSO is using IOPLEX Jespa - the only pure java implementation of NTLMv2 based authenticator. NTLMv2 protocol is not considered insecure.

Does EasySSO work with Atlassian Cloud

No. At the moment Atlassian Cloud doesn't allow the necessary form of integration to have EasySSO available there.

Why do I need a new computer account

Once configured with a computer account EasySSO starts playing a role of a computer on your network for the purpose of authentication and the underlying process is similar to those happening when a user is trying to access a shared drive on another machine.

Can I use a user account

No. The account must be a dedicated computer account and a password must be set explicitly. Once configured (with the computer account) EasySSO starts playing a role of a computer on your network, for the purpose of authentication, and the underlying process is similar to those happening when a user is trying to access a shared drive on another machine.

Can I use a service account

No. The account must be a dedicated computer account and a password must be set explicitly. Once configured (with the computer account) EasySSO starts playing a role of a computer on your network, for the purpose of authentication, and the underlying process is similar to those happening when a user is trying to access a shared drive on another machine.

Can I use the account of the same server/vm/box that Jira is installed on

No. The account must be a dedicated computer account and a password must be set explicitly. Once configured (with the computer account) EasySSO starts playing a role of a computer on your network, for the purpose of authentication, and the underlying process is similar to those happening when a user is trying to access a shared drive on another machine.

I have multiple instances of EasySSO - how many computer accounts do I need

You will need to create as many computer accounts as you have instances of EasySSO running in Atlassian applications. Due to changes introduced by Microsoft in March 2015 with security patch MS15-027/KB3002657 there is now no way to avoid it. Each EasySSO instance is seen by the domain controllers as a computer on the network. When two instances use the same computer account sporadic failures and seemingly random login prompts to enter AD credentials via an in-browser popup may be observed while SSO works perfectly fine for the most users.

Why two licenses

EasySSO is a paid add-on distributed via Atlassian Marketplace and as such requires a license to function. IOPLEX Jespa is a 3rd party library that is required by EasySSO to function.

IOPLEX Jespa library is the only pure java implementation of NTLMv2 based authenticator. EasySSO integrates Jespa with Atlassian applications (JIRA and Confluence), providing the glue between the library code and Atlassian application code. Jespa library does all heavy lifting behind the scenes to authenticate a user - performing NTLMv2 challenge to the client (i.e. browser) and communicating with the Domain Controller. Due to the licensing restrictions we are unable to simply package IOPLEX Jespa within EasySSO and a separate download from ioplex.com is required. The library distribution can then be uploaded via EasySSO and installed within your Atlassian product.

The 2nd license is for Jespa library and the cost of the license is included in EasySSO license price.

After installing EasySSO my Application Links do not work

Please review item #13 on "How to Install EasySSO for JIRA" or "How to Install EasySSO for Confluence" pages. When building links between Atlassian applications NTLMv2 is not supported and as such EasySSO on the "server" end needs to be instructed to ignore the "client" application. If the "client" application has EasySSO as well, it needs to have similar configuration (i.e. to ignore the other one).

Can SSO be made available to users from different completely independent domains

At the moment no. In order for EasySSO to work, domains must have trust. In theory multiple computer accounts could be used to service different domains in the same instance of Atlassian application. However, the only way to choose which one to use would be via IP address of the client, as no other distinctive features exist at the time when EasySSO NTLMv2 challenge is performed. So far this doesn't seem to be acceptable to any customer who has raised this question. Recently added Kerberos support may hold the answer. Watch this space.

How to determine existing domain trust relationships

Please review How To Determine Trust Relationship Configurations KB from Microsoft. We recommend using nltest tool from a domain-joined workstation (not necessarily the server that will run EasySSO-enabled Atlassian application).

Please note, this assumes that the domain of the workstation that you are using is the same as the domain of the computer account you've specified in EasySSO Config.

Code Block
nltest /trusted_domains

This will produce a list of trusted domains.

How to determine existing AD sites

We recommend using nltest tool from a domain-joined workstation (not necessarily the server that will run EasySSO-enabled Atlassian application) to discover all AD sites. 

Please note, this assumes that the domain of the workstation that you are using is the same as the domain of the computer account you've specified in EasySSO Config.

Code Block
nltest /dclist:

If multiple sites are returned you will need to establish which one should be used from the server that will run the application, as others may not be accessible and will cause intermittent errors with EasySSO not being able to reach the domain controllers while rotating through the list in round-robin fashion (ironically for the sake of fault tolerance). The chosen site name should be entered in AD Site parameter in EasySSO config screen.

The following command will tell you what AD site the workstation you are running the command on is using. Please note that if the workstation is not the server where you are running the Atlassian application, the returned result may be different from the site that should be used on the server.

Code Block
nltest /dsgetsite

How to choose the site

You can use the list of the controllers returned by nltest (in the answer above - How to determine existing AD sites) or the alternative is to run the DNS query using nslookup command

Code Block
nslookup -type=SRV _ldap._tcp.dc._msdcs.<your domain>
 
e.g
 
nslookup -type=SRV _ldap._tcp.dc._msdcs.domain1.mycompany.org

This DNS lookup is what IOPLEX Jespa library is doing internally and should return the same records as nltest command

Then for each name you can run the following on the server

Code Block
nltest /server:<hostname> /query
e.g.
nltest /server:dc01.domain1.mycompany.org /query
nltest /server:dc02.domain1.mycompany.org /query
nltest /server:dc03.domain1.mycompany.org /query
...

...

How to determine AD forest

We recommend using nltest tool from a domain-joined workstation (not necessarily the server that will run EasySSO-enabled Atlassian application) to discover the AD forest. 

Please note, this assumes that the domain of the workstation that you are using is the same as the domain of the computer account you've specified in EasySSO Config.

Code Block
nltest /dsgetdc:

Are Mac OS X clients supported

Short answer: YES!

For years the answer was plain "No". Then it became "yes, but in an ugly way" as no browser on Mac OS X is yet capable of performing transparent NTLMv2 authentication instead presenting a "domain login popup".

To not make Mac users life uglier while we are making Windows crowd life easier we've introduced filtering by User-Agent strings so admins can configure EasySSO to ignore any mac clients and let them use the regular login screen i.e. "fallback" login.

Since October 2015 the answer is an empathic "YES!" (we use Macs ourselves) - with Kerberos support added a domain joined Mac can perform transparent automatic no-password asked login into EasySSO-enabled Atlassian application.

What about Linux

Same story as for Macs - YES!

I have NTLM working, how do I enable Kerberos support

Once you have your NTLM authentication working enabling Kerberos support on EasySSO side is as easy as checking a checkbox in the config screen.

Your AD/domain administrators will have to create a Service Principal Name for the service thus mapping the hostname of your application to the computer account used by EasySSO:

Code Block
setspn -s http/<computername>.<domainname>:<port> <easysso-computer-account>

e.g.

Code Block
setspn -s http/jira.mydomain.org:1990 jira$

You will need to run "setspn" for EVERY URL you use or plan to use when accessing the service. For example if you plan to access Confluence via long and short URL for example - you'll need to run setspn for both.

This command effectively tells the browser "when you are accessing this URL you can respond to Negotiate authorization challenge with Kerberos ticket targeted at this principal/computer". As such you need to enumerate all URLs that can potentially be used.

Browsers, especially those other then Internet Explorer may require some massaging before Kerberos and NTLM will be successfully negotiated.

Please review instructions for PingFederate while we are working on adding a similar section to our site - the actions to make EasySSO work will be equivalent.

Also please review the following page in the documentation for PingFederate in regards to hostname canonicalization, or reverse DNS lookups. If your setup is more complex than a standalone host with DNS containing A and PTR record - you will need to create additional Service Principal Name mappings.

Do take the possibility of different results for DNS resolution in different scenarios into account - intranet, extranet, VPN, etc. Having the same exact hostname resolve to a different IP address when on the internal network (to the host itself) than the one when on the external network (to the SSL appliance or firewall) is a very common scenario. This may require adding additional SPNs for the hostnames identified via reverse DNS lookup.

I have a proxy in front of my application do I need Kerberos Delegation enabled

No. The Kerberos ticket should be passed by the proxy to the EasySSO-enabled application as is.

I have a proxy in front of my application do I need to do something different for Service Principal Name

If you plan to access the service both via proxy (from outside?) and direct - you MAY need to create multiple mappings with "setspn" if the URLs are different, enumerating all URLs that can potentially be used.

Please review the following page in the documentation for PingFederate in regards to hostname canonicalization, or reverse DNS lookups. If your setup is more complex than a standalone host with DNS containing A and PTR record - you will need to create additional Service Principal Name mappings.

Do take the possibility of different results for DNS resolution in different scenarios into account - intranet, extranet, VPN, etc. Having the same exact hostname resolve to a different IP address when on the internal network (to the host itself) than the one when on the external network (to the SSL appliance or firewall) is a very common scenario. This may require adding additional SPNs for the hostnames identified via reverse DNS lookup.

...

NTLM works but with Kerberos I am getting "Mechanism level: Checksum failed" errors in the log

The most frequent cause of this is the mismatch in SPN that browser has composed for the server (i.e. what it thinks it is connecting to) and the mappings to the computer account that were created.

If the DNS name of the service is a CNAME, presence of the SPN for this name will trigger the sending of Kerberos ticket in response to Negotiate challenge, but the target SPN included in the ticket may not match the server name as browser may canonicalize the hostname.

Please review the following page in the documentation for PingFederate in regards to hostname canonicalization, or reverse DNS lookups. If your setup is more complex than a standalone host with DNS containing A and PTR record - you will need to create additional Service Principal Name mappings.

Do take the possibility of different results for DNS resolution in different scenarios into account - intranet, extranet, VPN, etc. Having the same exact hostname resolve to a different IP address when on the internal network (to the host itself) than the one when on the external network (to the SSL appliance or firewall) is a very common scenario. This may require adding additional SPNs for the hostnames identified via reverse DNS lookup.

The same error is returned when the SPN that browser is using is mapped to a different account. As such please verify the output of "setspn -s" carefully when adding SPNs for the computer account used by EasySSO.

NTLM works but with Kerberos I am getting "Encryption type AES256 is not supported" errors in the log

If once Kerberos is enabled and SPN is added you are getting an error similar to the below in the logs - you will need to perform extra actions on your server-side JRE/JDK

Code Block
jespa.security.SecurityProviderException: Failure unspecified at GSS-API level (Mechanism level: Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled)

The the security policy in the JRE/JDK being used needs updating. See here for details - "Support for AES encryption type", especially the Note below the page:

NOTE: The JCE framework within JDK includes an ability to enforce restrictions regarding the cryptographic algorithms and maximum cryptographic strengths available to applications. Such restrictions are specified in "jurisdiction policy files." The jurisdiction policy files bundled in Java SE limit the maximum key length. Hence, to use the AES256 encryption type, you will need to install the JCE crypto policy with the unlimited version to allow AES with 256-bit key.

The files for Java 8 can be obtained here;
http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html

Please read the README file that is inside the package and install the 2 jars accordingly.

Can I preemptively identify this problem before I try configuring Kerberos authentication

Yes!

Go to to https://www.howsmyssl.com/

The preference in the list of ciphers that your browser presents for SSL (can be seen in Given Cipher Suites area on this page) will be similar to the preference used when encrypting Kerberos ticket. Below is the example from IE11 on Windows 10. As you can see AES 256 is preferred by the browser and the problem will manifest itself in the absence of the strong security policies.

No Format
Given Cipher Suites

The cipher suites your client said it supports, in the order it sent them, are:
•TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
•TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
•TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
•TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
•TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
•TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
•TLS_RSA_WITH_AES_256_GCM_SHA384
•TLS_RSA_WITH_AES_128_GCM_SHA256
•TLS_RSA_WITH_AES_256_CBC_SHA256
•TLS_RSA_WITH_AES_128_CBC_SHA256
•TLS_RSA_WITH_AES_256_CBC_SHA
•TLS_RSA_WITH_AES_128_CBC_SHA
•TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
•TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
•TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
•TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
•TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
•TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
•TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
•TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
•TLS_DHE_DSS_WITH_AES_256_CBC_SHA
•TLS_DHE_DSS_WITH_AES_128_CBC_SHA
•TLS_RSA_WITH_3DES_EDE_CBC_SHA
•TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

Please note the default policies of the browsers and domains may change - so it would make sense to always install the strong policies where it is permitted by law.

How can I see if the client is doing NTLM or Kerberos

Kerberos will only be negotiated when it is possible in the first place. Even if you have it configured and it has worked at any given moment the browser may have to fall back to NTLM

If you need to identify what is being used at this moment the only way to recognize this is from the logs at log level 4.

Once Kerberos authentication is enabled in EasySSO settings - the server and the browser will start exchanging "Negotiate" headers.

If NTLM is still being used the value of the headers being sent by the client will start with "TlRMTV" and authorization will take 3 request/response roundtrips:

Code Block
languagebash
tail -f jespa.log | grep -e "C:" -e Authorization -e Authenticate -e Exception -e authenticated

may result in something similar to:

No Format
2015-11-08 15:57:29: HttpSecurityService: C: GET /jira/
2015-11-08 15:57:29: HttpSecurityService:   WWW-Authenticate: Negotiate
2015-11-08 15:57:29: HttpSecurityService: C: GET /jira/
2015-11-08 15:57:29: HttpSecurityService:   Authorization: Negotiate TlRMTVNTUAABAAAAl5JI4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==
2015-11-08 15:57:29: HttpSecurityService:   WWW-Authenticate: Negotiate TlRMTVNTUAACAAAAEAAQADgAAACVgoliFU7pvXnv8yDFAAAAAAAAAFgAWABIAAAABQLODgAAAA9UAEUAQwBIAFQASQBNAEUAAgAQAFQARQBDAEgAVABJAE0ARQABAAwAagBlAHMAcABhADEABAAYAHQAZQBjAGgAdABpAG0AZQAuAG8AcgBnAAMAEABLAHkAbwBuAC4AbABhAG4AAAAAAA==
2015-11-08 15:57:29: HttpSecurityService: C: GET /jira/
2015-11-08 15:57:29: HttpSecurityService:   Authorization: Negotiate TlRMTVNTUAADAAAAGAAYAJgAAAD4APgAsAAAABAAEABYAAAAEgASAGgAAAAeAB4DDFAELAAFYKIYgYBsR0AAAAPtcH9EMsNOMFTt0vhJXwAZVQARQBDAEgAVABJAE0ARQB0AGUAcwB0AHUAcwBlAHIAMQBXAEkATgAtAEQARABFADAATwA0ADIASQBUAEsAMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnlo2EpEYci9RBB47bLJXrAQEAAAAAAAC86Aw10RnRAXb9POTsFtKhAAAAAAIAEABUAEUAQwBIAFQASQBNAEUAAQAMAGoAZQBzAHAAYQAxAAQAGAB0AGUAYwBoAHQAaQBtAGUALgBvAHIAZwADABAASwB5AG8AbgAuAGwAYQBuAAgAMAAwAAAAAAAAAAEAAAAAIAAAcRkMdbuNloshgez1/yX1nNTlxK+ZtsZGwScVNIFXwGgKABAAAAAAAAAAAAAAAAAAAAAAAAkAJABIAFQAVABQAC8AMQA5ADIALgAxADYAOAAuADEAMwAzAC4AMQAAAAAAAAAAALmhXivglKIpv+DHkwe6PmE=
2015-11-08 15:57:29: NETLOGON: Session authenticated
2015-11-08 15:57:29: HttpSecurityService: 192.168.133.135:57548: testuser1 successfully authenticated

If Kerberos is being used the headers will not start with "TlRMTV" and authorization will take only 2 request/response roundtrips:

No Format
2015-11-08 13:36:35: HttpSecurityService: C: GET /stash/
2015-11-08 13:36:35: HttpSecurityService:   WWW-Authenticate: Negotiate
2015-11-08 13:36:35: HttpSecurityService: C: GET /stash/
2015-11-08 13:36:35: HttpSecurityService:   Authorization: Negotiate YIIL8AYGKwYBBQUCoIIL5DCCC+CgMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCC6oEggumYIILogYJKoZIhvcSAQICAQBugguRMIILjaADAgEFoQMCAQ6iBwMFACAAAACjggTNYYIEyTCCBMWgAwIBBaEOGwxURUNIVElNRS5PUkeiJDAioAMCAQKhGzAZGwRIVFRQGxFreW9uLnRlY2h0aW1lLm9yZ6OCBIYwggSCoAMCARehAwIBCqKCBHQEggRw3WqqH+T+Gz6nyIaqYMj/YTY3/MPNH5jtZcVsUxJM7RnrML8cPEedLiKgRlNbYLYCLy6VuOtq6W8j9noIHSQC3zPEUKp86WPrsRXSIiD5qtYbr0EtRfiBmgjhT9G+nfhe8EgAKLDWoZbqA8C8dSxXacSRC2UzIpT+PnUpIeLSYHNifqd63eXD/hfq2JZKdw1h1mB0xSvCSW0hsR0n7JPJ9VdfjEdio7OHXwMEHEki4sQZfqnudxypg7vpNo+RUB36hwXfzy/UDHi2+bH+OlrM4JgGSNgKg45E8zF7iq/zox8TtV66PW+4xKKXzJVUe03rdz7kXA31XIYDU6HcY/my7TL5RSSd2lcn9oNl37gr9Y+Oyt937BmeyEYAlInHLGXGBSwYgXJhFVRSUFnZgubbvigV43AVjWdiQukV3DXktBkdFpHfVbNRAZs0M65fEwNEZDZ/GyCTe/bhQWXJWVEYyvbGVYo4XmlEE9h7b3okOCm9gO9YVPoeSIW6QQhbEIsGSKbvjCZuYspFX3EVHOnf+nvpKYDLJkaI99J2GI6ybEt0o3BxPmcqI8GQO/eDiyaBlKW7QVaitY2SQ9QE4fqCdfU9o3n7HU27APswQl8vHoKFzQEtc2CQByJ7m8CLaM4JzqDpB/jPcLHY9H62MwYW7vhfgtWxVeiF0/JikPc/Ow5YWMuHTrfkXVKEMZzg5EjgUN16AGfC7lU8Psm8ig+Q/8dhqPctl4Kw52Dg0i4faOBYXN7DTJ5/4/BzF6kNkuGzOaYbo5/V1zUMNjeO0Uj8BPLaKWxye4/7cwbqNoRNpIrXd8orrURlx/jx0BdzK7FWjrrZic6MRN1NPgSX/20L+FtgrLuVOtHK0BYH+n/ZXYdgevcvTL/iXtcigWFI8A2oThMMG9dP242L0hjoxHD2Fu7Y8p4PDPsGkqiNDbqD/wxK5aGxBHwlH8GpN0aYSEsbDABe4griHKV/efZn1hjayFYx8l9SjcVmp33E+ZJm5w6f4I+usUuP1e1wr5H5bFNMcygn/j3eOP+RMPT9khTEdZLp/6QiKMQJr08xdxA2+tv3/o92qpdZyCXkwmfMX/o9JlPbJbfmMub9X/ksBMNX4w3K5Rfh2zvD+DJbjhPl0gFmr5yURU633RrwbqCczbl3317A1UIeVv8SjdS1opiGGq1I1+1MrqIHMHY596bCgij1zJO7OG4aKl4//yf/eUQzX/ZxXIMyRxexOUdp0AuwpV7w7ug5rnuOM6shV4NBVjst00iXu1u421IOwrXaUwZutYJVffxTBcTOGqWHYA0VXzwgVc6xJeaLD40nqdCjbOBgfgaWgMsTXoL0GqI2/3CXe7d4J4lFsaI5Z26pRmeq6pbymDZY1SHpaf8R6i3Faf93nV3CrSQsr+qLuLZ05hY4Pu+mRSRH3YG4trtJJaWgLFnale2iwsqrIsxIo/GyeYY8STTnxzoxjx1s/pxqZQfZJOo7vcHXv3VHPsJ8Adf59S5++cmQ+e5UfarezbC7pZSkggalMIIGoaADAgEXooIGmASCBpQwmEVjIKoxqRwzVaZX6RG3hjHAGoOrps5qSR/mO1ZbbYXNf5f4x2UyDU4qmy9okiXg5JdepbdxLnhLXob1k9xqRuBddlcbF8fsayzGD1zkwCUKGpE0ZgrS8BjVDKOVaMffgsPWsm0NGGzE4CaCdi1RcD3Gl8LABfRjDRWznsUlUx1AQil7MwQaAfKCljF9s96ou/WUyfoN1j6NFt5JmWIPy3pVgsvt471Bipa6k0xwCgk8NL9axStTF7uQM8IMb17BoICbj5hhKfPFp/lfVdnKDOqVYvA/eWY2jEttE4EDG4jf2qoZH4AR/eMONngJ7SF7RcxCASeQ96Q5CzNZ3QYXK7scn1vDnto73EzBR4ORkbZ7sRC4kAuFifN8AJlTJ9EjvhkfF902z5chH3rF24sbe72cSBk9oPNAKkq731qE0dqnPTGYDLpSQ58yoeEhM2q4fqiY6Rc+uimKtp5r0QRJ5Fpr7JdhO4nHOI8hibLl/LfNwP/YYwmWqeTq40+Lhy+dGvrp6UA8k71cH92nqzfV6qDok+CivWp1AyuC6TK6AnncOWHSgxXfiUzL/wBwqEmwScYHAjLbtpf3geKD8GMOtyXNl4jF6KqX9JI+AMBTDZEi5zbWwns54tTZZuNg2l3mk35nkCjKwxWzBigJckSz9LMN5qxOUKtsamoiPlM0bWSs5wQnj/J86M+T6VX5OVXP3Z8/dCJ6cWK7TB/hKve14fSF2yAzhhcOQzL0Ki6y6rJe8JhDl0sJwWN8O7hA0/vrlKoRRWLltrJ/9eOGonlYLybLraByzMvny3TIsWYkq4MqHPYaNFlpfts/1+dwJ3q43ad4doxlKutV+8qUG4APY82Jay4AJsVp4LrbynhR6T4FcBstofyzAA+uj0QmO28T9QKujLcbHpfjEshJPxkBEd+QcUK6n/AV0wQ4AY9RDW+hcjmBRyY1R2YZ+DGlf3GqsgqMvOJPjvGXws8Xi9X2NJnTwmQ/PRFC2/4myLtOCgsH9K/CkVmjzXwgEwL8ysx+1gWkvoAQeMl/24PBWZ7sil0OmBNagC/gAg88zGE/XwMZiM1dj+en1m1wXkmX3NhQkDG4O46gcrbTM5do2by5RLX/z9ff246dRTDE32JkTBRj1/MeAsx4v7akFssOMtiOtlTA0VslFsTWfTlHHh2/Tg1izh8dlY5LFdWjdf6IszYRwWds17SI6LP/vLpALqxIniiHES2kPfTJWGIBuggmOrzC73rRxZoBV8w/1P00udE3FXcieEHNdECZJxCWqqSFDn7BqNqusI/vpnC/TzmmqNxh7wJA36e8cm1ZQY+2ZBElZ9Kmn8CelchgbMQDczGFbjuev1aVbnBDhMTgHYFaK3rD9N70WMAfQcJCLAkxrHe1eEDXsdE3r1sXrezN8M2JQKYrpZEMkyVZ1GR7AWASnNPOUPYRkVTRF7il6iMGYweEYQjzcjqSOD85sGfxtqgzzoqWMNUrVlzdEU22dyq2DQlf8Jo6yw8SA+XCrkcVZR/4x+s96rblj3ZExpRW8mSNe6LISEJkb3PJYzqgHAyDUkCEZhdDKndLWjnZ0w8EB9Y+NxgT8X5U5gztyhOjYCqk24hHxujS0C0cnqBj6wgKXcK4wVzMpsM+52iCYVYI8eTMUnpkAGFMaWc1yTP/IsSJM7PYsJA2wSRVfihr+l0oXXoN3y9rc0OJQefKnRFVR9LXFfL/Ej/bGlM85wV+W5nznnfAt3pX0CiAHtoCZm5luKB4FICesYCRcpTiHbQGkesocvw5K5xS5z6ZShtFgEghSETP9i/U3isHJLFLXe5cT2Rsn6RuUGjYii1pZlPsoBobf8SkGIPHvnT8OF6kkGumO4iAYNyT1FLCxroWXWzqmZ95m1miypCzoOxSeBMg0dYGvN4r++kaAuPav3qWaVeVQPeAySmr7BnK5n8lNdkRAtw8vZZOqcW2fgzQPsS2HjYfD9xJyOY3ztMnHKjhTBJI9GullZlcUI7x3ms4YAYHDgW+z+Kvn9ZGTcyESLeleqV7xAITpYCdvAl1bKBlvls7AORYtRz900QQC2zoD0uPkwIskkn0XhQKES/eNj/XdLyKFvw+JOA5cIt6joZFbEWu5Zfe7bUs2hp6jX/jaIGOv+V7CsP3EZE6SmGhh3LfnroqN0NG6OXZOC5pddcGM+xalP7WOBIMVzP1MgswncSjXEfcl17qh2zqd7IyOuLT7YWjIU1aG
2015-11-08 13:36:35: HttpSecurityService: 192.168.133.136:63668: testuser1 successfully authenticated

 

How to configure NGINX as reverse proxy so SSO works

When NGINX is action as a reverse proxy, i.e. performs HTTP (port) forwarding it requires additional configuration to correctly work with the SSO state machine.

 For Apache and IIS it is described on pages 3-4 of the IOPLEX Jespa Operators Manual and is mentioned in our install instructions.

The page from Atlassian - Integrating JIRA with NGINX, can serve as a reference for general configuration of NGINX when used with Atlassian products.

The configuration requires an additional line (#8 in the example below) to be added. The purpose of the line - add a "Jespa-Connection-Id" header that has a value combining remote client's IP address and port.

Also Kerberos-based Single Sign-On can cause large header values being sent so line #11 is recommended

Code Block
linenumberstrue
server {
	listen www.atlassian.com:80;
	server_name www.atlassian.com;
	location /jira {
		proxy_set_header X-Forwarded-Host $host;
		proxy_set_header X-Forwarded-Server $host;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header Jespa-Connection-Id $remote_addr:$remote_port;
		proxy_pass http://jira-hostname:8080/jira;
		client_max_body_size 10M;
		large_client_header_buffers  4 32k;
	}
}

Once you reconfigured your NGINX this way the telltale sign of it working will be in jespa.log at log level 4 - see *bold values*, showing the remote client's IP address and port as opposed to proxy's one. Some values have been obscured with ****

2015-03-13 19:44:37: HttpSecurityService: C: GET /rest/mywork/latest/status/notification/count
2015-03-13 19:44:37: HttpSecurityService: Request Headers: host=********* | x-requested-with=XMLHttpRequest | accept=application/json, text/javascript, /; q=0.01 | referer=******* | accept-language=en-AU | accept-encoding=gzip, deflate | user-agent=Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0) | dnt=1 | cookie=confluence-sidebar.width=55; confluence.browse.space.cookie=space-blogposts; JSESSIONID=592AF09B33C01304B1D068007FA41E93 | authorization=NTLM TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw== | jespa-connection-id=172.16.9.39:62624 | x-forwarded-for=172.16.9.39 | x-forwarded-host=******* | x-forwarded-server=******** | connection=Keep-Alive
2015-03-13 19:44:37: HttpSecurityService: Loading session state from session 592AF09B33C01304B1D068007FA41E93
2015-03-13 19:44:37: HttpSecurityService: Importing provider state
2015-03-13 19:44:37: HttpSecurityService: Authorization: NTLM TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==
2015-03-13 19:44:37: HttpSecurityService: 172.16.9.39:62624: token.length=40
2015-03-13 19:44:37: HttpSecurityService: AuthContext: 172.16.9.39:62624

 

Children Display
styleh4
sortcreation

Content by Label
showLabelsfalse
max5
spacesEASYSSO
showSpacefalse
sortmodified
reversetrue
typepage
labelseasysso faq

...