Switch to the most recent Kibana configuration format and SAML/OIDC endpoints. #50652
Conversation
azasypkin
added
>docs
|
Pinging @elastic/es-docs (>docs) |
|
Pinging @elastic/es-security (:Security/Authentication) |
azasypkin
force-pushed
the
issue-xxx-rename-kibana-oidc-endpoint
branch
from
b92b461 to
9dc5765
Compare
azasypkin
changed the title
/v1/ from Kibana OIDC callback URLs.
|
@azasypkin are the new kibana endpoints usable in 7.x ?If so after which minor ? We should
|
Yes
It depends on specific endpoint, but we'd like to mention this only starting since 7.7+ when new config is introduced.
We do this already in Kibana.
UA is not capable of doing this yet, elastic/kibana#54702. Once we can do this - we'll definitely do this.
We filed the appropriate issue some time ago (already linked to this one), but it's up to the Cloud to update it. There is lots of friction for non-Cloud developers to do this (e.g we don't have access to CI if PR is failing etc.) and we agreed that Cloud will do that for us.
We'll do this separately in the scope of Cloud SSO initiative since Cloud we'll have to use new config format anyway. Regarding URLs - the issue mentioned above should cover that as well. |
Nice, I was wondering if we should throw a deprecation in elasticsearch logs too. I think kibana is enough though
Yap, sorry, I missed that. |
| {kib}. This login will not use SAML credentials, and will rely on one of the | ||
| other security realms within {es}. Only users who have a username and password | ||
| for a configured {es} authentication realm will be able to login via this page. | ||
| If {kib} is configured in this way, then users will be presented with the choice |
There was a problem hiding this comment.
Minor edit, removing future tense:
| If {kib} is configured in this way, then users will be presented with the choice | |
| If {kib} is configured in this way, users are presented with a choice |
| other security realms within {es}. Only users who have a username and password | ||
| for a configured {es} authentication realm will be able to login via this page. | ||
| If {kib} is configured in this way, then users will be presented with the choice | ||
| at the Login Selector screen whether to use username and password, and rely on one |
There was a problem hiding this comment.
Minor edit, splitting long sentence:
| at the Login Selector screen whether to use username and password, and rely on one | |
| at the Login Selector screen. They can provide a username and password, rely on one |
There was a problem hiding this comment.
Thanks! I kept and before rely on since these "other security realms" are used only when username and password are provided, but let me know if there is a better way to express this (in this sentence we're describing just two options - either SAML or not-SAML).
There was a problem hiding this comment.
Hmmm... maybe that will be more obvious if we change the order. I'll provide a new suggestion.
| If {kib} is configured in this way, then users will be presented with the choice | ||
| at the Login Selector screen whether to use username and password, and rely on one | ||
| of the other security realms within {es}, or log in with SAML. Only users who have | ||
| a username and password for a configured {es} authentication realm will be able to |
There was a problem hiding this comment.
Minor edit, removing future tense:
| a username and password for a configured {es} authentication realm will be able to | |
| a username and password for a configured {es} authentication realm can |
Co-Authored-By: Lisa Cawley <[email protected]>
|
@elasticmachine merge upstream |
Kibana recently did a bunch of changes in configuration format and endpoint names:
/api/security/v1/oidcand/api/security/v1/oidc/implicit(deprecated since 7.6) routes in favor of/api/security/oidc/callbackand/api/security/oidc/implicitrespectively/api/security/v1/oidcroute used for 3rd-party initiated login in favor of/api/security/oidc/initiate_loginserver.xsrf.whitelistnowxpack.security.authc.saml|oidcis deprecated andxpack.security.authc.providerschanged format that will allow to define ES realm name within provider definition itself.Preview: