Use SSO to create CLI token

[yuriadams]

What is the feature/fix?

Docs:

configure

Configure necessary fields to make the authentication using login command.
Fields:

• Provider: Which identity provider will be used to authenticate. Supported providers: okta.
• Client ID: The OpenID Connect client ID provided by your Identity Provider.
• Client secret: The OpenID Connect client secret provided by your Identity Provider.
• Issuer: A unique string that identifies the provider issuing a request.
• Callback URL: A unique string that identifies the callback url that the idp will redirect the request after authorize the customer.

Usage

    convox sso configure

or

    convox sso configure -p PROVIDER -c CLIENT_ID -s CLIENT_SECRET -i ISSUER -u CALLBACK_URL

or we can add following environment variables:

SSO_PROVIDER
SSO_CLIENT_ID
SSO_CLIENT_SECRET
SSO_ISSUER
SSO_CALLBACK_URL

Examples

    convox sso configure
    SSO Provider: 
    SSO Client ID: 
    SSO Client Secret: 
    SSO Issuer:
    SSO Callback URL: 
    OK

login

Authenticate your CLI using a identity provider.

Usage

    convox sso login

You will be redirected to the browser to your fill the credentials in your identity provider.

Requirements

Is necessary to configure the identity provider to add the convoxID that refers with the user id in the console. Also, is required to add this field in the token claim.
Also, configure the callback endpoint in the customer application, for example, http://localhost:8090/authorization-code/callback. Port and the path can be customized by the customer.

Does it has a breaking change?

No

Video Record

https://convox602-my.sharepoint.com/:u:/r/personal/yuri_adams_convox_com/Documents/Convox%20-%20SSO%20Demo.zip?csf=1&web=1&e=Qqro5W

Checklist

• New coverage tests
• Unit tests passing
• E2E tests passing
• E2E downgrade/update test passing
• Documentation updated
• No warnings or errors on Deepsource/Codecov

[nightfury1204]

@yuriadams nice job.

but userid as convoxID poses a security issue. it should't be a user id. since we once someone knows the user id, they can easily login in. also its hard to change if it gets compromised since it's act as an identifier of the user in our system and all the data associated with it.

also can every user in the sso okta can configure identity provider?

[yuriadams]

@yuriadams nice job.

but userid as convoxID poses a security issue. it should't be a user id. since we once someone knows the user id, they can easily login in. also its hard to change if it gets compromised since it's act as an identifier of the user in our system and all the data associated with it.

also can every user in the sso okta can configure identity provider?

@nightfury1204 thank you very much for your feedback.

First question:

This is a great point that I don't have the answer what's the the best way. A improvement I did this morning was add the convoxID as a token claim. So, this token will be sent to the console and the console will be responsable to check if the id is there, so the cli won't "know" the convox id because it will be in the token payload. So, your concern is more the person who's configuring the okta knows the user id? Do you have a suggestion about how can we make this link between the okta and our console? Create like a new token for the user and this token to be included in okta ui maybe?

Second:
No, actually the customer needs to configure his own okta application, we don't control. In the video record I just show which requirements the customer needs to do before configure our CLI.

[Twsouza]

the code looks good, just some errors message that could be more helpful to add more context.

[Twsouza]

@yuriadams is this good to review?