Users only know there login credentials, they usually don't know what a federation protocol is, the keystone authentication type or where the ECP endpoint for example:
--os-auth-type v3samlpassword --os-identity-provider <name of idp in keystone> --os-identity-provider-url <ECP endpoint> --os-protocol <federated protocol> --os-username <federated username> --os-password --os-auth-url <keystone endpoint> --os-project-name <federated project id> --os-project-domain-name <federated domain id> --os-identity-api-version 3
The RC file provided by horizon is strictly only of use to locally authenticated keystone users.
as Adam pointed out, most of the information is provided by: openstack --debug token issue
but that raises a chicken and egg scenario So, there is a requirement to provide 'obscure openstack variables' to users after they log in to horizon
Users only know there login credentials, they usually don't know what a federation protocol is, the keystone authentication type or where the ECP endpoint for example:
--os-auth-type v3samlpassword provider <name of idp in keystone> provider- url <ECP endpoint> domain- name <federated domain id> api-version 3
--os-identity-
--os-identity-
--os-protocol <federated protocol>
--os-username <federated username>
--os-password
--os-auth-url <keystone endpoint>
--os-project-name <federated project id>
--os-project-
--os-identity-
The RC file provided by horizon is strictly only of use to locally authenticated keystone users.
as Adam pointed out, most of the information is provided by:
openstack --debug token issue
but that raises a chicken and egg scenario
So, there is a requirement to provide 'obscure openstack variables' to users after they log in to horizon