Chapter 5. Troubleshooting

5.1. Test the Keystone Mapping Rules

It is recommended you verify that your mapping rules work as expected. The keystone-manage command line tool allows you to exercise a set of mapping rules (read from a file) against assertion data which is also read from a file. For example:

  1. The file mapping_rules.json has this content: 

    [
    {
        "local": [
            {
                "user": {
                    "name": "{0}"
                },
                "group": {
                    "domain": {
                        "name": "Default"
                    },
                    "name": "federated_users"
                }
            }
        ],
        "remote": [
            {
                "type": "MELLON_NAME_ID"
            },
            {
                "type": "MELLON_groups",
                "any_one_of": ["openstack-users"]
            }
        ]
    }
]

  2. The file assertion_data.txt has this content: 

    MELLON_NAME_ID: 'G-90eb44bc-06dc-4a90-aa6e-fb2aa5d5b0de
MELLON_groups: openstack-users;ipausers

  3. If you then run this command: 

    $ keystone-manage mapping_engine --rules mapping_rules.json --input assertion_data.txt

  4. You should get this mapped result: 

    {
  "group_ids": [],
  "user": {
    "domain": {
      "id": "Federated"
    },
    "type": "ephemeral",
    "name": "'G-90eb44bc-06dc-4a90-aa6e-fb2aa5d5b0de"
  },
  "group_names": [
    {
      "domain": {
        "name": "Default"
      },
      "name": "federated_users"
    }
  ]
}
Note

You can also include the --engine-debug command line argument, which will output diagnostic information describing how the mapping rules are being evaluated.

5.2. Determine the Actual Assertion Values Received by Keystone

The mapped assertion values that keystone will use are passed as CGI environment variables. To retrieve a dump of those environment variables:

  1. Create the following test script in /var/www/cgi-bin/keystone/test with the following content: 

    import pprint
import webob
import webob.dec


@webob.dec.wsgify
def application(req):
    return webob.Response(pprint.pformat(req.environ),
                          content_type='application/json')

  2. Edit the /var/lib/config-data/puppet-generated/keystone/etc/httpd/conf.d/10-keystone_wsgi_main.conf file setting it to run the test script by temporarily modifying the WSGIScriptAlias directive: 

    WSGIScriptAlias "/v3/auth/OS-FEDERATION/websso/mapped" "/var/www/cgi-bin/keystone/test"

  3. Restart the container: 

    podman restart keystone
  4. Attempt to login, and review the information that the script dumps out. When finished, remember to restore the WSGIScriptAlias directive, and restart the HTTPD service again.

5.3. Review the SAML messages exchanged between the SP and IdP

The SAMLTracer Firefox add-on is a useful tool for capturing and displaying the SAML messages exchanged between the SP and the IdP.

  1. Install SAMLTracer from this URL: https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/
  2. Enable SAMLTracer from the Firefox menu. A SAMLTracer pop-up window will appear in which all browser requests are displayed. If a request is detected as a SAML message a special SAML icon is added to the request.
  3. Initiate a SSO login from the Firefox browser.
  4. In the SAMLTracer window find the first SAML message and click on it. Use the SAML tab in the window to see the decoded SAML message (note, the tool is not capable of decrypting encrypted content in the body of the message, if you need to see encrypted content you must disable encryption in the metadata). The first SAML message should be an AuthnRequest sent by the SP to the IdP. The second SAML message should be the assertion response sent by the IdP. Since the SAML HTTP-Redirect profile is being used the Assertion response will be wrapped in a POST. Click on the SAML tab to see the contents of the assertion.