Auth plugins should be linked to Federation Protocol

[Adam Young]

When setting up Federation, if the protocol needs an new auth plugin, the current mechanism is to add it to the methods list for the [auth] section. However, this has the effect of linking them all together, when the real method should be to link the auth plugin with the protocol. Most of the Federation code is going to require the mapped plugin, but that should not be included in the stack that is then used for password or token based authentication.

[Colleen Murphy (krinkle)]

Adam, can you clarify what the problem is exactly? I don't understand what you mean by "linking them all together" or "that should not be included in the stack that is then used for password or token based authentication". I don't see any reason the mapped auth plugin shouldn't be added to the [auth]/methods list.

The way I see it, where we're failing is by tightly coupling the name of the auth plugin with the name of the federation protocol. The name of the protocol is limited to what's available as an auth plugin, which is basically this list: http://git.openstack.org/cgit/openstack/keystone/tree/setup.cfg?h=14.0.0#n66

It would be better if we could create a federation protocol with an arbitrary name and then have a field that describes the valid auth plugin, e.g. `openstack federation protocol create myarbitraryprotocol --auth-plugin mapped`, is that what you're talking about?

[Adam Young (ayoung)]

A config section for [token] starts with:

# Allowed authentication methods. Note: You should disable the `external` auth
# method if you are currently using federation. External auth and federation
# both use the REMOTE_USER variable. Since both the mapped and external plugin
# are being invoked to validate attributes in the request environment, it can
# cause conflicts. (list value)
#methods = external,password,token,oauth1,mapped,application_credential

This value is used for the URL

/v3/auth/tokens

however, the `external` config is really only supposed to be used with /OS-FEDERATION.

If External is specified here, it is to allow a user to do LDAP + Kerberos or some other variation like that, not Federation.

If we don't have external specified, when we set up Federation we need to go and enable here, but that implies it is usable for direct token issue as well, which is incorrect. There is the potential for this to be misconfigured, and allow access when it is not suppose to be provided. That would happen if, say, Kerberos was to be used as a Federation-only protocol, but was then allowed with LDAP, too.

[Colleen Murphy (krinkle)]

How should we fix this? Do we need a separate option for federated auth methods?

[Adam Young (ayoung)]

I don't think so. Federated auth is always 'External' so there is no need
to make that explicit.

On Tue, Oct 9, 2018, 4:26 AM Colleen Murphy <email address hidden> wrote:

> How should we fix this? Do we need a separate option for federated auth
> methods?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1643112
>
> Title:
> Auth plugins should be linked to Federation Protocol
>
> Status in OpenStack Identity (keystone):
> Triaged
>
> Bug description:
> When setting up Federation, if the protocol needs an new auth plugin,
> the current mechanism is to add it to the methods list for the [auth]
> section. However, this has the effect of linking them all together,
> when the real method should be to link the auth plugin with the
> protocol. Most of the Federation code is going to require the mapped
> plugin, but that should not be included in the stack that is then used
> for password or token based authentication.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/keystone/+bug/1643112/+subscriptions
>