Tokenless authentication is broken

[Colleen Murphy]

When trying to use tokenless authentication, authentication fails with the following traceback:

http://paste.openstack.org/show/742271/

git bisect shows this is the commit that introduced the bug: 0dc5c4edabd5cb0455ffe1c4f8cf8369f64b2197

Steps to reproduce:

(Can start out with configuring devstack with the tls-proxy service to have devstack generate a root CA but then you need to remove the default proxy configuration in /etc/apache2/sites-available/http-services-tls-proxy.conf it generates)

Configure keystone behind Apache with mod_ssl and the following mod_ssl options:

<VirtualHost *:443>
    SSLEngine On
    SSLCertificateFile /opt/stack/data/devstack-cert.pem
    SSLCACertificateFile /opt/stack/data/CA/root-ca/cacert.pem
    SSLOptions +StdEnvVars
    SSLVerifyClient optional
    SSLUserName SSL_CLIENT_S_DN_CN
    SetEnv REMOTE_DOMAIN openstack
</Virtualhost>

In keystone.conf set up external authentication and tokenless auth:

[tokenless_auth]
trusted_issuer = CN=Root CA,OU=DevStack Certificate Authority,O=OpenStack
[auth]
methods = password,token,external
external = Domain

Create a client certificate with the example user values from the tokenless auth docs, signed by the root CA:

$ openssl req -out CSR.csr -new -newkey rsa:2048 -nodes -keyout privateKey.key
$ openssl x509 -req -in CSR.csr -CA /opt/stack/data/CA/root-ca/cacert.pem -CAkey /opt/stack/data/CA/root-ca/private/cacert.key -days 365 -out john.pem -CAcreateserial

Create the IdP, mapping and protocol:

$ openstack identity provider create ad9b5af1ba36ffc36e1fbf7af5e83e25aebf66bbfefc12eed0313a875e6f9663
$ openstack mapping create x509map --rules rules.json
$ openstack federation protocol create x509 --mapping x509map --identity-provider ad9b5af1ba36ffc36e1fbf7af5e83e25aebf66bbfefc12eed0313a875e6f9663

Create a local user with role assignments:
$ openstack domain create openstack
$ openstack user create john --domain openstack
$ openstack role add --user john --user-domain openstack --project demo member

Get a token for the user:

$ curl -v -k -s -X POST --cert john.pem --key privateKey.key -H "x-project-name: demo" -H "x-project-domain-id: default" https://192.168.122.248/identity/v3/auth/tokens -d '{"auth": {"identity": { "methods": [ "external" ], "external": { "user": { "name": "john", "domain": { "name": "openstack" } } } } } }' -H 'content-type: application/json'

Try to validate the token with tokenless auth (as in the documented example):

$ curl -v -k -s -X GET --cert /home/devuser/john.pem --key /home/devuser/privateKey.key -H "x-project-name: demo" -H "x-project-domain-id: default" https://192.168.122.248/identity/v3/auth/tokens -H "x-subject-token: <token>"

[Lance Bragstad (lbragstad)]

I was able to verify this locally. The only difference I noticed was in the second to last step, where you're able to get what appears to be a scoped token using a certificate. When I do this, I always get back an unscoped token regardless of the headers I pass in [0] (e.g., x-project-id or x-project-name + x-project-domain-id). This could be a separate issue though and something I was talking to gyee about today in IRC [1].

Otherwise - when I try and validate the unscoped token from the last step, I do see the 500.

[0] https://pasted.tech/pastes/c79647db136625ea6a2ad38c767162e7fcd2d831.raw
[1] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2019-01-23.log.html#t2019-01-23T21:32:29

[Guang Yee (guang-yee)]

So looks like there are two problems.

1) We assume that request_context will always have a token_reference, which is not true in the case
of X.509 tokenless auth.

2) We are no longer using auth_context when formulating the credentials for RBAC. Instead, we are using the Oslo request_context.

https://github.com/openstack/keystone/blob/master/keystone/common/rbac_enforcer/enforcer.py#L388
https://github.com/openstack/oslo.policy/blob/master/oslo_policy/policy.py#L981

[Lance Bragstad (lbragstad)]

For history on #2, we opted to generate context objects from oslo_context, which is a pattern used by other services. As opposed to having an alternative approach for generating RBAC values that deviated from other OpenStack services.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/635993
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=1b261e8bec31a6de3905557abde0da93d5c0437a
Submitter: Zuul
Branch: master

commit 1b261e8bec31a6de3905557abde0da93d5c0437a
Author: Guang Yee <email address hidden>
Date: Fri Feb 8 16:56:40 2019 -0800

    populate request context with X.509 tokenless cred information

    Fixes X.509 tokenless auth by properly populating the request context
    with the necessary credential information. Since Stein release, RBAC
    has been using the credential information from the Keystone request
    context instead of the authentication context. Therefore, we'll need
    to populate the request context with the necessary credential
    information from the X.509 tokenless authentication context.

    Closes-Bug: 1811605
    Change-Id: I170a91e9ac36990d1e7ec4165dd0337b8f06a938

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/keystone 15.0.0.0rc1 release candidate.