[19.04] idp protocol names from keystone-fid-service-provider relation data are not added to authentication methods

Bug #1828015 reported by Dmitrii Shcherbakov
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Keystone Charm
Fix Released
High
David Ames

Bug Description

'mapped' is an authentication plugin name which is also used as a protocol name in OpenStack documentation. Protocol names need to be added as "methods" into keystone.conf and the charm currently hard-codes 'mapped' as if it was the only protocol to be supported (the confusion comes from the fact that authentication plugins are usually listed there).

https://docs.openstack.org/keystone/queens/admin/federated-identity.html#configuring-federation-in-keystone

"Configure authentication drivers in keystone.conf by adding the authentication methods to the [auth] section in keystone.conf. Ensure the names are the same as to the protocol names added via Identity API v3."

"saml2 and openid are instances of the mapped plugin. These must match the name of the of the federation protocol created via the Identity API. The other names in the example are not related to federation."

Usage examples in unit tests:
https://opendev.org/openstack/keystone/src/branch/stable/queens/keystone/tests/unit/test_auth_plugin.py#L213-L217

There is nothing preventing us from supporting other names and specifying something like this:

methods = external,password,token,oauth1,totp{% for m in fid_methods -%},{{ m }}{% endfor -%}

Besides use-cases like SAML or OIDC the "mapped" authentication plugin is also used for tokenless x509 auth which relies on a section that specifies the protocol as well:

    [tokenless_auth]
# ...
    protocol = x509

So, changing the current code to avoid hardcoding 'mapped' and 'openid' and only adding protocol names if charm-keystone is related to other charms like keystone-saml-mellon will not break compatibility for existing deployments.

Tags: cpe-onsite
description: updated
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to charm-keystone (master)

Fix proposed to branch: master
Review: https://review.opendev.org/657562

Revision history for this message
Dmitrii Shcherbakov (dmitriis) wrote :

Subscribed ~field-medium.

Revision history for this message
David Ames (thedac) wrote :

Posted this in the PR but as an update to the bug here it is:

Dmitrii,

OK, I am convinced this is necessary. However, in order to fix Bug #1828015 and 1828018 I'd like to create a context for auth methods that does all the logic in the python rather than in the jinja template.

Let me know if you don't have the time to do this and I'll jump in.

Revision history for this message
David Ames (thedac) wrote :
Changed in charm-keystone:
milestone: none → 19.07
assignee: Dmitrii Shcherbakov (dmitriis) → David Ames (thedac)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to charm-keystone (master)

Reviewed: https://review.opendev.org/659393
Committed: https://git.openstack.org/cgit/openstack/charm-keystone/commit/?id=a103c15e40612b4c2c801543896bda4bbd5396f0
Submitter: Zuul
Branch: master

commit a103c15e40612b4c2c801543896bda4bbd5396f0
Author: David Ames <email address hidden>
Date: Wed May 15 14:53:48 2019 -0700

    Use AuthMethod context

    Rather than use hard coded auth methods, use the protocal named passed
    over the keystone-fid-service-provider relation.

    Also, when using federation do not allow the "external" method as they
    are mutually exclusive.

    Change-Id: I08f0632630d7f0e8d2d7ddb057e02f9febf9ad6f
    Closes-Bug: #1828015
    Closes-Bug: #1828018

Changed in charm-keystone:
status: In Progress → Fix Committed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to charm-keystone (stable/19.04)

Fix proposed to branch: stable/19.04
Review: https://review.opendev.org/661537

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to charm-keystone (stable/19.04)

Reviewed: https://review.opendev.org/661537
Committed: https://git.openstack.org/cgit/openstack/charm-keystone/commit/?id=84dac3c3626e1f434ccc9a88f8301d8b567bad4f
Submitter: Zuul
Branch: stable/19.04

commit 84dac3c3626e1f434ccc9a88f8301d8b567bad4f
Author: David Ames <email address hidden>
Date: Wed May 15 14:53:48 2019 -0700

    Use AuthMethod context

    Rather than use hard coded auth methods, use the protocal named passed
    over the keystone-fid-service-provider relation.

    Also, when using federation do not allow the "external" method as they
    are mutually exclusive.

    Change-Id: I08f0632630d7f0e8d2d7ddb057e02f9febf9ad6f
    Closes-Bug: #1828015
    Closes-Bug: #1828018
    (cherry picked from commit a103c15e40612b4c2c801543896bda4bbd5396f0)

David Ames (thedac)
Changed in charm-keystone:
status: Fix Committed → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on charm-keystone (master)

Change abandoned by Dmitrii Shcherbakov (<email address hidden>) on branch: master
Review: https://review.opendev.org/657562

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.