Example of okta-config-jira.xml

<configuration>
    <applications>
        <application>
            <md:EntityDescriptor entityID="http://www.okta.com/exknbojcmy7JNaqkm0h7" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"><md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><md:KeyDescriptor use="signing"><ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><ds:X509Certificate>MIIDpDCCAoygAwIBAgIGAWwFJnwgMA0GCSqGSIb3DQEBCwUAMIGSMQswCQYDVQQGEwJVUzETMBEG
A1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNU2FuIEZyYW5jaXNjbzENMAsGA1UECgwET2t0YTEU
MBIGA1UECwwLU1NPUHJvdmlkZXIxEzARBgNVBAMMCmRldi03ODAzNTQxHDAaBgkqhkiG9w0BCQEW
DWluZm9Ab2t0YS5jb20wHhcNMTkwNzE4MTI1NDAzWhcNMjkwNzE4MTI1NTAzWjCBkjELMAkGA1UE
BhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWExFjAUBgNVBAcMDVNhbiBGcmFuY2lzY28xDTALBgNV
BAoMBE9rdGExFDASBgNVBAsMC1NTT1Byb3ZpZGVyMRMwEQYDVQQDDApkZXYtNzgwMzU0MRwwGgYJ
KoZIhvcNAQkBFg1pbmZvQG9rdGEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
ndgkp3yzBMxDH/0UNIgZdcCfcxdCdZtkWbDotp1k22qIcJVMFaRF5uNTYil/MW87eFOdBrW1Aqxg
48y/41jzabL791GdX5wYgMsRVw7jTSaYSXVqW6la1ustpn/rz4IkPQFWBF7MImejiFISdCh/GBzS
Q++bEU9F/4kVnf2QVABrYG/vhliY3GL/VDhLBXHv2FKi20TJrk+XFh0+dYBKnCJ3nXeQY/91+IHT
2AMFVAXvGqpok7+jdeb9lWDd3Ca7YTKPclGIkxeAA7OND5DzNsgQvSNH4ZUZCwJiSNul/n8YVsiW
eS1ZbGv8qiVcjniOtZ6OzV8rp3BYfuNHuz8YhQIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQAQ1K1V
ar2Dfr0SiyXHNLl47k3PNLNdXtQik5cIxjm8EXfFsArwWLo3ge/xeENHi/pLbpF5NgLsc/xj88ij
ZGo484Skg7dD2vm2YE5Wf7vdEE3aaqhM7OJ5PnRZTQZuFTcWKs2x+/I0mqlChIxigpL8et5Efm+R
z52/f/P4giCrI+/QBVt9MNCHotVCqsmmCWaRKBO195TYp17EbSx4FgNsogYGcWRdshPGKaNhUADu
P38usXc4Ig4uu/Y0KXv+ZkvguZwF1KTD73+nsEnWzmug2ULaz1X13OzqPJfZZ1We//RPFlnIKMnu
T4RGAcCYdyrcDxn/sPhvgClO1gcmfFnH</ds:X509Certificate></ds:X509Data></ds:KeyInfo></md:KeyDescriptor><md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:email</md:NameIDFormat><md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://advania.zhb.se/app/jira_onprem/exknbojcmy7JNaqkm0h7/sso/saml"/><md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://advania.zhb.se/app/jira_onprem/exknbojcmy7JNaqkm0h7/sso/saml"/></md:IDPSSODescriptor></md:EntityDescriptor>
        </application>
    </applications>

    <allowedAddresses>
        <!--If this section defined, it describes which IP addresses can use Okta Authenticator to log into Jira.
                This block takes precedence over spUsers block below.-->
		<!--
        <oktaUsers>
            <ipFrom>192.168.3.10</ipFrom>
            <ipTo>192.168.3.220</ipTo>
        </oktaUsers>
		-->
        <!--If this section defined, it describes which IP addresses can use Native Jira autheticator (login/pass) to log into Jira.
        This block has lower priority than oktaUsers block.-->
		
        <spUsers>
            <ipFrom>158.177.188.50</ipFrom>
            <ipTo>158.177.188.50</ipTo>
        </spUsers>
		
    </allowedAddresses>
 
    <!--If this section defined, SP flow can be disabled for users,
        listed below. In this case they will be forced to login using their login/pass. -->
	<!--
    <spUsers>
        <username>user1</username>
        <username>user2</username>
        <username>user3</username>
    </spUsers>
	-->
    <!--If this section defined, SP flow can be disabled for users assigned to groups in Jira,
       listed below. In this case they will be forced to login using their login/pass. -->
	
    <spGroups>
        <groupname>local-auth</groupname>
        <groupname>jira-local-auth</groupname>
    </spGroups>
	
    <!-- If this section defined, authenticator won't be used for URLs listed below -->
    <spUrls>
        <url>servicedesk/customer/portal</url>
    </spUrls>
	
	
    <oktaProtectedUrls>
        <url>/browse/</url>
        <url>/secure/</url>
        <url>/okta_login.jsp</url>
    </oktaProtectedUrls>

    <loginUri>https://<org>/app/jira_onprem/<appid>/sso/saml</loginUri>
</configuration>

Filed under: Atlassian, Okta by goran
Kommentarer inaktiverade för Example of okta-config-jira.xml

Enable https in Atlassian

To enable https in JIRA, this line should be added in server.xml

<Connector SSLEnabled="true" acceptCount="100" clientAuth="false" connectionTimeout="20000" disableUploadTimeout="true" enableLookups="false" keyAlias="jira-domain-com" keystoreFile="C:\Program Files\Atlassian\JIRA\jre\lib\security\cacerts" keystorePass="<jks password>" keystoreType="JKS" maxHttpHeaderSize="8192" maxSpareThreads="75" maxThreads="150" minSpareThreads="25" port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" scheme="https" secure="true" sslProtocol="TLS" relaxedPathChars="[]|" relaxedQueryChars="[]|{}^\`"<>" useBodyEncodingForURI="true"/>

In Windows the file’s path is typically:

C:\Program Files\Atlassian\JIRA\conf\server.xml

Filed under: Atlassian by goran
Kommentarer inaktiverade för Enable https in Atlassian

Import Let’s Encrypt to JKS

You can perform a manual verification – with the manual plugin. 

certbot -d jira.domain.com --manual --preferred-challenges dns certonly

Certbot will then provide you an instructions to manually update a TXT record for the domain in order to proceed with the validation.

Please deploy a DNS TXT record under the name
_acme-challenge.jira.domain.com with the following value:

667drNmQL3vX6bu8YZlgy0wKNBlCny8yrjF1lSaUndc

Once this is deployed,
Press ENTER to continue

Once you have updated DNS record, press Enter, certbot will continue and if LetsEncrypt CA verifies the challenge, certificate is issued as normally.

In Linux the certs will be in

/etc/letsencrypt/live/jira.domain.com

cd into that directory and execute (the name will at import set the keyalias):

openssl pkcs12 -export -in cert.pem -inkey privkey.pem -name jira-domain-com -out jira.p12

Set the password to the same as the JKS file. Default password is:

changeit

Copy jira.p12 to the folder where the default keystore cacerts is. In Windows the cacerts is usually in:

C:\Program Files\Atlassian\JIRA\jre\lib\security

Since keytool command is in relationship to cacerts normally:

..\..\bin\keytool.exe

The import command would be (in the cacerts directory):

..\..\bin\keytool -importkeystore -deststorepass [password] -destkeystore cacerts -srckeystore jira.p12 -srcstoretype PKCS12

If there is a need to import the chain.pem the command would be:

..\..\bin\keytool -import -alias letsencrypt -trustcacerts -file chain.pem -keystore cacerts

The added line in server.xml:

<Connector SSLEnabled="true" acceptCount="100" clientAuth="false" connectionTimeout="20000" disableUploadTimeout="true" enableLookups="false" keyAlias="jira-domain-com" keystoreFile="C:\Program Files\Atlassian\JIRA\jre\lib\security\cacerts" keystorePass="<jks password>" keystoreType="JKS" maxHttpHeaderSize="8192" maxSpareThreads="75" maxThreads="150" minSpareThreads="25" port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" scheme="https" secure="true" sslProtocol="TLS" relaxedPathChars="[]|" relaxedQueryChars="[]|{}^\`"<>" useBodyEncodingForURI="true"/>

Filed under: Atlassian by goran
Kommentarer inaktiverade för Import Let’s Encrypt to JKS

Atlassian Introduction

Identity Management of Atlassian software is a science in it self. There are two different approaches with Atlassian Cloud and Atlassian Servers. Atlassian Cloud is managed through a global directory shared amongst the cloud services. This identiry is often referred to as Atlassian ID. To ensure uniqueness of the identity, the user’s email is being used as the ID. Read More on Atlassian ID…

In Atlassian Server, the identity is usually a combination of a “in application” directory, and back end directories. It is possible to do management of the identities through API, but more commonly the functionality of integrating LDAP directories as a back end is used. Read More on Atlassian Server Directories…

Okta can integrate with both Atlassian Cloud and Atlassian Servers, both in regards to Access Control (AC or SSO) and Identity Management (IdM). The integration with Atlassian Cloud has to go through Atlassian ID, and requires an additional license, Atlassian Access. The integration with Atlassian Server includes support for both AC and IdM, without additional licensing. The IdM is easiest to manage through the feature of Okta as a LDAP service in the cloud. Okta offers a jar file and configuration examples for the basic use case of SAML, both IdP and SP initiated use cases.

Filed under: Atlassian, Atlassian by goran
Kommentarer inaktiverade för Atlassian Introduction