provide a 'whoami' service for authenticated users

> This is not very useful. - and I need a working RC file to get this far!

You need to be authenticated in order for keystone to know who you are. How could keystone possibly be able to identify you if you haven't authenticated? Same as `whoami` on the command line, you have to have logged into the system already for it to work. I think I'm not fully understanding the request, can you give an example of how you see it working?

> .....I love keystone

<3

The response in a Keystone token reques provides this data, it is just not exposed in the CLI.

try

openstack --debug token issue

The mass of the data there is the service catalog.

openstack whoami could do a token fetch and then display a subset of the data from it.

If you get an unscoped token, it almost acts like what you want:

"POST /v3/auth/tokens HTTP/1.1" 201 324
{"token": {"issued_at": "2018-11-29T15:48:48.000000Z", "user": {"domain": {"id": "default", "name": "Default"}, "password_expires_at": null, "name": "<email address hidden>", "id": "redacted"}, "methods": ["password"], "expires_at": "2018-11-29T16:48:48.000000Z", "audit_ids": ["redacted"]}}

Thanks Colleen, so the example would be an authenticated user in Horizon.
This is where users go to get their API credentials and there is no reliable resource either in Horizon or Keystone to get them.

insofar as Horizon is concerned, the admin user can configure web SSO, a trusted dashboard and a mapping from
federated protocol to federated identity provider, this all works well for Horizon users, however when a user selects 'API Access' from within horizon (so, an authenticated user) the clouds.yaml and openstackrc.sh file provided by horizon will be wrong, users then have to ask an admin, or dive pretty deep into keystone documentation to find out how they would build and openrc file.

I think keystone has all of required information in it's database with the exception of

--os-identity-provider-url <ECP endpoint>

so, perhaps this could be a flag when registering and IDP with keystone,

openstack identity provider create --
--column --domain --format --noindent --remote-id
--description --enable --help --prefix --remote-id-file
--disable --fit-width --max-width --print-empty --variable

the whoami service would populate the values of these variables for an authenticated user:

--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

I realize this would be different for other federation protocols/Identity providers, at the moment neither user not administrator can glean this information from keystone.

So, Users don't know how to configure the openstack client or get the information they need to use the API
and administrators can't

would be nice
openstack user show <user-id>

domain_id xxx
enabled True/False
id xxx
name xxx
email
federated True/False
identity_provider idp-remote-id
protocol federation protocol
authentication keystone authentication method
mapping federated projects
roles roles mapped to user
groups groups mapped to user
inherited_roles roles assigned to users groups

horizon could make an equivalent API call to
'openstack user show whoami' for project scoped API credentials

this is a bit easier to read:

openstack user show <user-id>

domain_id.............. xxx
enabled................ True/False
id..................... xxx
name................... xxx
email...................xxx
federated.............. True/False
identity_provider...... idp-remote-id
protocol............... federation protocol
authentication......... keystone authentication method
mapping................ federated projects
roles.................. roles mapped to user
groups................. groups mapped to user
inherited_roles........ roles assigned to users groups
users_projects......... projects
users_group_projects....projects

perhaps that's a bit verbose, but this is what we have at the moment

domain_id
enabled
id
name
options {}
password_expires_at

thanks Adam, I noticed this, back to horizon team to extrapolate that? it would also be useful to finger users on the command line though

> so the example would be an authenticated user in Horizon.
This is where users go to get their API credentials and there is no reliable resource either in Horizon or Keystone to get them.

From comment #3, if a user has already authenticated to Horizon, shouldn't they already know their credentials? Also, at that point, they should be able to download a copy of their RC file through the UI.

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

I may still be missing something, but this sounds like a horizon request. If a user is authenticated horizon could validate their token and display the useful bits of information.

Keystone provides the data needed. This should be an opentackapi, CLI, and Horizon change.

Linked Horizon to this bug for historical context. The maintainers for python-openstackclient no longer use launchpad, so we'll have to track this separately with Storyboard [0].

[0] https://storyboard.openstack.org/#!/project_group/80

horizon closed the bug I reported with the option of globally disabling API credentials

https://bugs.launchpad.net/horizon/+bug/1795851

horizon now provides a way for operators to customize their own clouds.yaml and openrc (tracked by bug 1795851).

It sounds reasonable to provide more useful clouds.yaml and/or openrc *automatically*. This should be tracked by this bug.

Due to the lack of contributors in horizon, I (as my horizon team hat) would like to wait someone who can work on this.

From horizon developer perspective, it is not easy to setup all available authentication scenarios.
The identity API reference provides examples only for a standalone password auth case.
There is no example for saml and other authentication ways and it is not easy to know what kind of clouds.yaml and openrc should be provided. This is a bottleneck of implementing this feature in horizon( and this is the reason that I chose a way to custom templates in bug 1795851).
Some information from authentication experts (from keystone team) would be appreciated much.

Just commenting on this bug again - there is still very valid requirements for other projects be aware of federated keystone

-now broken after configuring a federation protocol

- clouds.yaml / openrc in Horizon
- zun (cloud shell)
- magnum (Cloud Provider OpenStack in k8s)

> now broken after configuring a federation protocol
>
> - clouds.yaml / openrc in Horizon

horizon provides a way for operators to customize their own clouds.yaml and openrc (tracked by bug 1795851).
Doesn't it work?

If someone would like to move this forward more, we (as horizon developers) need an example of the token auth response of /v3/auth/tokens for non-password case (like federation) [1]. An example like comment #7 above is not sufficient because we cannot know how we organize openrc/clouds.yaml information. [2] is an example response for a simple password auth.

[1] https://docs.openstack.org/api-ref/identity/v3/index.html?expanded=validate-and-show-information-for-token-detail,password-authentication-with-unscoped-authorization-detail#password-authentication-with-unscoped-authorization
[2] http://paste.openstack.org/show/787351/