Conversation
5ca783d to
367ac0a
Compare
| }, | ||
| } | ||
|
|
||
| _, err = args.plugins.CreatePlugin(ctx, req) |
There was a problem hiding this comment.
Don't we expose an API like we do with Okta? It would be nice to stop creating those plugins directly and start using the same API that the UI does
There was a problem hiding this comment.
I suspect that it would be the best way to provide the sort of extended validation that @flyinghermit is suggesting as well, which we really can't do right now because all of the requisite code is on teleport.e.
flyinghermit
left a comment
There was a problem hiding this comment.
Looks good, just a few comments to ensure cli installation handles default dependencies and validation that is on par with the plugin enrollment supported in the UI.
| }, | ||
| }, | ||
| } | ||
|
|
There was a problem hiding this comment.
before installing plugin, I think we should check if saml service provider for the identity center is installed and guide user to do so if it isn't.
There was a problem hiding this comment.
Not sure what you mean - do you mean the SAML setup for Okta, or the SAML IdP for IC to call into?
There was a problem hiding this comment.
I meant for the SAML IdP. Though I realized that this is not required for the use case we are trying to address for a customer, so my initial comment is somewhat invalid.
My new found concern here is that, once we release these CLI based integration configuration, although we specifically implemented this to one customer that wants to use system credential and defer auth to their IdP, it still gives chance for other customers to try this feature. In that case, they might end up in a bad state and we should avoid providing footgun where possible. For example, they might try integration with system credential but manage auth via SAML IdP.
Since we have no way to detect and prevent such usage, what do you think about adding a flag --no-saml-idp-auth (or something similar) to differentiate this behaviour. And if the --no-saml-idp-auth flag is NOT set, we check for SAML service provider.
There was a problem hiding this comment.
I'm not opposed in principal, but I think it would be better in a separate PR, mainly because I'd like a bit more time to think about the UX and I want to get this out the door.
But yeah, I can imagine some flags like
--[no-]saml-idp-auth Configure the integration with/without a SAML Identity Provider service.
--saml-idp-provider PROVIDER-NAME The name of the SAML IdP provider service to validate. Defaults to `whatever-actual-default-is`.
| }, | ||
| }, | ||
| } | ||
|
|
There was a problem hiding this comment.
I meant for the SAML IdP. Though I realized that this is not required for the use case we are trying to address for a customer, so my initial comment is somewhat invalid.
My new found concern here is that, once we release these CLI based integration configuration, although we specifically implemented this to one customer that wants to use system credential and defer auth to their IdP, it still gives chance for other customers to try this feature. In that case, they might end up in a bad state and we should avoid providing footgun where possible. For example, they might try integration with system credential but manage auth via SAML IdP.
Since we have no way to detect and prevent such usage, what do you think about adding a flag --no-saml-idp-auth (or something similar) to differentiate this behaviour. And if the --no-saml-idp-auth flag is NOT set, we check for SAML service provider.
391330f to
8a691c7
Compare
Merge commits are not allowed on this repository
76383ea to
2031bf9
Compare
8a691c7 to
22fcfb5
Compare
Adds a comand-line installation tool for the AWS Identity Center integration. Co-authored-by: Marek Smoliński <marek@goteleport.com> Co-authored-by: Trent Clatke <trent@goteleport.com>
22fcfb5 to
da0cc30
Compare
Co-authored-by: Zac Bergquist <zac.bergquist@goteleport.com>
|
@smallinsky See the table below for backport results.
|
Backports #51239 Adds a comand-line installation tool for the AWS Identity Center integration. Co-authored-by: Marek Smoliński <marek@goteleport.com> Co-authored-by: Trent Clatke <trent@goteleport.com> Co-authored-by: Zac Bergquist <zac.bergquist@goteleport.com> --------- Co-authored-by: Trent Clatke <trent@goteleport.com> Co-authored-by: Zac Bergquist <zac.bergquist@goteleport.com>
Backports #51239 Adds a comand-line installation tool for the AWS Identity Center integration. --------- Co-authored-by: Marek Smoliński <marek@goteleport.com> Co-authored-by: Zac Bergquist <zac.bergquist@goteleport.com>
What
AWS CLI to install AWS IC plugin with local creds.
usage:
Depends-On: #52239