Horizon Provides wrong RC file

[Robert Duncan]

The are many ways to authenticate to keystone service saml, openid, ldap, etc.
each use case has it's own environment variables requirements to make a successful API request.

for example saml2 openrc file needs to contain:

--os-auth-type v3samlpassword
--os-identity-provider <name of ido in keystone>
--os-identity-provider-url <ECP endpoint>
--os-protocol saml2
--os-username <federated username>
--os-password
--os-auth-url http://sp.keystone:5000/v3
--os-project-name demo
--os-project-domain-name Default
--os-identity-api-versione 3

OIDC, ldap, mellon, k2k - they are all different.

The RC file provided by horizon is wrong, maybe most of the time.
https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/api_access/templates/api_access/openrc.sh.template

Since these files are only available to users after they log in, they should be provided dynamically from keystone service.

[Akihiro Motoki (amotoki)]

What horizon can know are limited to information included in token response. Horizon cannot know all required information to cover all possible authentication mechanism. From this reason, I think what horizon can support is only the basic password authentication.

Possible workaround is to provide a way to disable download links of openrc and clouds.yaml. When an operator uses a different auth method, they can disable the links.
Another possible solution is to provider a way to define a custom template for "openrc".

Does it sound reasonable?

[Akihiro Motoki (amotoki)]

Regarding the last paragraph "Since these files are only available to users after they log in, they should be provided dynamically from keystone service.", there is nothing we can do in the horizon side. We suggest you to propose such feature to keystone. Once keystone supports such feature via API, horizon can implement it as GUI support.

[Robert Duncan (rduncan-t)]

Thanks Akihiro - you are quite right.
I have logged it up with the keystone team

https://bugs.launchpad.net/keystone/+bug/1805817

but those guys don't play by anybody's rules but their own, nobody else's, not even their own.
I think they'll back port it all the way to Austin though, probably even further.

[Akihiro Motoki (amotoki)]

One more question as you seems to have saml2 environment.
Does the response of keystone token contains enough information to construct your openrc?
If so, theoretically horizon can prepare openrc file for saml2 env (though I have no such environment so I cannot test it.)

[Robert Duncan (rduncan-t)]

Yes, the information is there, for example "openstack --debug token issue", I can test something if you like.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/627050

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/627051

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/627050
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=c6baf007341aab17035bb5e77a6ab8143b069cd4
Submitter: Zuul
Branch: master

commit c6baf007341aab17035bb5e77a6ab8143b069cd4
Author: Akihiro Motoki <email address hidden>
Date: Sun Dec 23 04:13:07 2018 +0900

    Allow to hide openrc and clouds.yaml download links

    Operators now can control whether the links of "Download OpenRC" and
    "Download clouds.yaml" are displayed or not via new settings
    SHOW_OPENRC_FILE and SHOW_OPENSTACK_CLOUDS_YAML.
    openrc and clouds.yaml files provided by horizon now assume
    the basic simple deployment and do not cover keystone authentication
    like saml2, openid and so on. The default openrc and clouds.yaml
    from horizon do not make sense for such environments.

    Change-Id: I1407a24387c7d7bd2c20c995cebf1350f8090e72
    Partial-Bug: #1795851

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/627051
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=e832c8549b3cb7c0f4671668a5b404374eb8a64b
Submitter: Zuul
Branch: master

commit e832c8549b3cb7c0f4671668a5b404374eb8a64b
Author: Akihiro Motoki <email address hidden>
Date: Sun Dec 23 05:57:41 2018 +0900

    Allow to specify custom templates for clouds.yaml and openrc

    Change-Id: I1ef6899f4d14c660eba50f16e813c280657475fc
    Closes-Bug: #1795851

[Lance Bragstad (lbragstad)]

I posted some thoughts in the keystone bug, but asking them here, too.

[Lance Bragstad (lbragstad)]

Does Horizon glean RC file information for a user from the token body? Most of what's being asked for here is already in the token itself.

[Akihiro Motoki (amotoki)]

Yes, horizon collects RC file information from the response of GET /token keystone API.

What we are suffering is a lack of well covered examples for various auth methods like saml, ldap and so on.
This blocks horizon support as it is not easy to setup such environments to test them actually.

[Robert Duncan (rduncan-t)]

I think I may have confused matters in what I am asking for but, they are just values, the variable names are listed in the OpenStack cli docs and the values are returned in a token response.

https://docs.openstack.org/python-openstackclient/pike/cli/man/openstack.html

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/horizon 15.0.0.0b2 development milestone.

[Akihiro Motoki (amotoki)]

OSC document provides a list of options but we don't know what are valid combination and have no good examples. Otherwise, horizon cannot provide good openrc and clouds.yaml.

If someone is interested in supporting more flexible openrc, feel free to work on this in bug 1805817.

I have no bandwidth on work on it to cover all supported authentication mechanism and validate them (even if I can implement it).