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:
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"] } ] } ]
The file
assertion_data.txt
has this content:MELLON_NAME_ID: 'G-90eb44bc-06dc-4a90-aa6e-fb2aa5d5b0de MELLON_groups: openstack-users;ipausers
If you then run this command:
$ keystone-manage mapping_engine --rules mapping_rules.json --input assertion_data.txt
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" } ] }
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:
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')
Edit the
/var/lib/config-data/puppet-generated/keystone/etc/httpd/conf.d/10-keystone_wsgi_main.conf
file setting it to run thetest
script by temporarily modifying theWSGIScriptAlias
directive:WSGIScriptAlias "/v3/auth/OS-FEDERATION/websso/mapped" "/var/www/cgi-bin/keystone/test"
Restart the container:
podman restart keystone
-
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.
-
Install
SAMLTracer
from this URL: https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/ -
Enable
SAMLTracer
from the Firefox menu. ASAMLTracer
pop-up window will appear in which all browser requests are displayed. If a request is detected as a SAML message a specialSAML
icon is added to the request. - Initiate a SSO login from the Firefox browser.
-
In the
SAMLTracer
window find the firstSAML
message and click on it. Use theSAML
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 anAuthnRequest
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 theSAML
tab to see the contents of the assertion.