Add new zip for example SAML configuration files that reflect latest version

[cwillum]

Description

These changes add a new saml-example-custom.zip file containing customize-docker-compose.yml, customize-config.yml, and customize-opensearch-dashboards.yml files for use as the fully functioning SAML example. These changes also include edits to documentation so that steps accord with the new files.

The opensearch-dashboards.yml file contains the server.xsrf.allowlist setting. For version 1.3 this setting must remain server.xsrf.whitelist to conform to code for that version. Therefore, I'll create a new PR for that download. This PR covers versions 2.x and should work for subsequent major releases.

Issues Resolved

Fixes #618

Checklist

• By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and subject to the Developers Certificate of Origin.
  For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[cwillum]

Since we can't view the contents of the zip file here in GitHub, I'm pasting the note I added to the image settings in the docker-compose.yml file directing users to change the version number. The steps also include instruction to perform this edit. But I'm pasting the note in the file here for visibility and for review:

image: opensearchproject/opensearch:latest # replace "latest" with your preferred OpenSearch version number before launching in production: for example, 2.6.0.

[cwillum]

@opensearch-project/security I'm trying to resolve this issue with the SAML example zip file getting stale with each new version release. I've added steps to have users modify the docker-compose.yml file after download with OpenSearch version number in the proper image fields. I also added comments in the YAML file instructing users to do the same. The comment in the docker-compose.yml file looks like this:

image: opensearchproject/opensearch:latest # replace "latest" with your preferred OpenSearch version number before launching in production: for example, 2.6.0.

Could you have a look at this edit and see if it looks and sounds accurate/makes sense. Thanks.

[peternied]

I wouldn't recommend the tag latest, instead lets use 2. This will point to whatever the latest v2.X.X version of OpenSearch that has been released, this should ensure this client will always startup with modifying these instructions.