If you have a setup where you have different environments such as staging/development/testing and production, there are a bunch of things that you should make sure are working before rolling out our app to production. You can also use it if you don't have such a setup to make sure everything is configured.

Login:

• Make sure your Identity Provider is configured properly by logging in via https://youratlassianproduct/plugins/servlet/samlsso . The expected result is that no errors are displayed and that the user ends up being logged in.
• Test SSO by explicitly browsing https://youratlassianproduct/plugins/servlet/samlsso before enabling the redirection. As long as the redirection is not enabled, existing users are not affected.
• If user creation or update has been configured, make sure that new users are created and existing users are updated when you change their attributes (name, email) on the IdP.
• If user creation or update has been configured AND groups are assigned, also make sure that those groups are properly assigned or removed.
• If redirection is supposed to be enabled for all users, make sure this works as well. 
• Ensure that you have at least one local user with system administrator privileges and a password set to be able to login to the system if SSO fails for any reason.

Multiple Identity Providers (if configured):

• Make sure that the above login checks work for all configured Identity Providers.
• Make sure that your IdP Selection method is configured and working. If you use request header selection or email domain selection, make sure to test the selectors via the live test feature (≥ 2.0).

Security:

• Make sure that all IdPs are configured in our app to have a signing certificate. The SAML SingleSignOn allows to omit the IdP certificate, but this should never done in production.
• If you want to restrict non-SSO login, make sure the templates are edited to remove references to the nosso-login page (Note that this does not prevent people from manually calling the login site via the ?nosso URL argument. Disabling this is intentionally not possible to prevent admin lockout). 
• Unless your Identity Provider requires it, make sure the Service Provider → Security settings are at the default values.

Other:

• If you're logging in Jira Service Desk customers, make sure redirection on the Service Desk customer portal is working.
• If you've connected your Confluence to a JIRA Service Desk as a knowledge base, make sure the knowledge base articles are working.
• If you're using a Load Balancer, make sure sticky user sessions are enabled.
• If you're using a Monitoring system, make sure it still works even with redirection enabled. 
• If your IdP team requires that organization and contact information are given in the SP metadata, make sure those are entered (≥ 2.0).
• If you have to configure non-SSO or force SSO URLs for any reason, make sure they are configured.

During migration:

If you export your config from staging and import it in production:

• Make sure to reset the entity ID in the Service Provider tab (only necessary in ≥ v2.0).

• Depending on your security setup, make sure to generate a new private key and certificate OR import your existing private key and certificate.
• Depending on your Identity Provider, you may need to reimport the IdP Metadata to fit the production setup (for example: ADFS uses the same metadata for every SP, but Azure AD generates new endpoints and certificates for different SPs)

Always:

• Make sure you configure your IdP properly to support the production system (new URLs, metadata etc).

Rollback/Fallback

For every good Roll-Out Plan, you should have an equally good roll-back/fallback plan.

• If the instance is still booting with the app configured:

  • You can always circumvent the SSO redirection to log in with your instance credentials: Cannot access Jira / Confluence/ Bitbucket/ Bamboo/ Fisheye-Crucible anymore - Bypass SSO

    
    

    Application	Nosso URL
    JIRA	https://<jira-baseurl>/login.jsp?nosso
    Confluence	https://<confluence-baseurl>/login.action?nosso
    Bitbucket	https://<bitbucket-baseurl>/login?nosso
    Bamboo	Bamboo 5: https://<bamboo-baseurl>/userlogin!default.action?nosso Bamboo 6 and later: https://<bamboo-baseurl>/userlogin!doDefault.action?nosso
    Fisheye-Crucible	https://<fisheye-baseurl>/login?nosso

    
    
    
  • If you're getting IdP or signing-related errors, make sure to double check that both the IdP and your instance is using the correct metadata.
  • Make sure to download support information before rolling back the changes, ideally including one or more authentication trackers from our app: Go to the System & Support tab, click "Show all", check all the failed login trackers you'd like to include, then click "Collect information"
    
    
• If your instance crashed, you can disable the app at startup: Application startup issue - Disable SSO Plugin
• If your instance crashes when you try to install the app, make sure you have enough free RAM.
  
  

And lastly: Contact our support via our customer portal. If you managed to download the support information, please attach them, as well as, if possible, screenshots of the relevant errors.

If you have suggestions on improvements to this list, feel free to tell us by sending a short message to our support mail address: atlassianplugins@resolution.de . We value your input.