-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Discuss] What to call the Kibana profile vs the Cloud profile #82755
Comments
Pinging @elastic/kibana-security (Team:Security) |
Thanks for raising this @ryankeairns.
My preference is to keep self-managed and ESS-managed consistent in terms of link names. Users migrating from one to the other shouldn't have to relearn that, and our docs shouldn't have to account for that discrepancy either.
The capabilities of this page are growing. Currently it just shows your user information, and maybe the option to change your password. However, we will soon be adding support for managing your own API Keys within this screen (#82005), so I still think there is benefit to keeping this around for ESS-managed installations. I could see user preferences living here as well, but I suppose that's TBD. |
This is interesting and surfaces a potential disconnect between teams regarding the long term vision of the user experience. It would be good to meet to talk through these before we get too far along. From a Cloud-first standpoint, we're unlikely to want to expose our users to two separate profile pages, particularly because post SSO the email and password can't be changed. The API keys are also interesting as we have to have a good explanation for users around when to use the Cloud API Keys vs the Stack ones, but thats a tangental, but different problem. Regardless, it would be great to have a chat and try to find at least a loose alignment on a wider long term vision for this. Who is the best person/people for that? |
++ let's include @arisonl & me from the Kibana security side. It'd be great to come to a common understanding before we evolve Kibana's user entity further |
Please include me as well. Security are the experts, I'd just like to share the context for the design side. |
Two user profiles would signify the opposite message of that of a unified security: i.e. that there are two parts to our security model and that they are conceptually disjointed enough to deserve separate views and entry points for users. I too would assume that those two should become one, in the mid/long term at least. As more than one efforts converge on the User profile we should definitely start thinking what lives and what will live in a unified user profile more holistically and how we gradually converge to a cloud-first experience. There are potential functional overlaps as well between the Kibana user entity and the Cloud user model. Might worth looping in @jowiho too, as @gjones sees fit -I believe you are working together. |
Upon further discussion on Nov 19, the agreed upon approach is to adjust the links for Cloud instances only, as follows:
As things progress with unified security management and Kibana profile settings, we will continue to regroup and assess the long term home for such settings. |
With the completion of #66825 , the profile menu in Kibana will soon (once the Cloud backend provides is complete) display links back to the Cloud UI.
One particular item we need to discuss further is the presence of two profile links - the longstanding 'Profile' link (fka Edit profile) for changing your password and the newly added 'Cloud profile' link. As you can see, having two profile links feels like an undesirable end state.
There are many factors at play here once we dig in: unified security management project, personal settings project, the current blocking of password changes for Cloud users (i.e. you change it at the Cloud admin level), etc.
Considerations
cc:/ @alexfrancoeur @gjones @legrego
The text was updated successfully, but these errors were encountered: