Consider Login-requirement / authentication to protect TraderX Demo Environment

[DovOps]

Feature Request

Description of Problem:

Do we want the traderx demo to be 100% open? This may cause bad actors to exploit the unauthenticated tool to inject offensive content, or other things, rather than just demonstrate the functionality.

Potential Considerations:

Does this create a barrier to exploration, or would people be hesitant? Is this difficult to implement? Do we want to do this?

[DovOps]

Recommend: Non-default option while doing development, but when deployed as an environment, ingress controller should enforce access control. (any major social+github SSO should be accepted) and logging usage.

Concerns: This stops being 'quick and easy' with a 'paywall-style' login.

[maoo]

I think that Github SSO would be the best option, in terms of accessibility from FINOS members and community at large.

I share the concern around the paywall-style limitation, though we could only limit input submission (ie add account) to logged users, assuming it's easy to implement.

I suppose that this change would only affect the frontend (specifically angular) component, which is where I lack of expertise; would be great to find someone with Angular experience who could contribute this feature.

[leandroyabut]

I think that Github SSO would be the best option, in terms of accessibility from FINOS members and community at large.

I share the concern around the paywall-style limitation, though we could only limit input submission (ie add account) to logged users, assuming it's easy to implement.

I suppose that this change would only affect the frontend (specifically angular) component, which is where I lack of expertise; would be great to find someone with Angular experience who could contribute this feature.

I have Angular experience so I would be happy to take a look at this issue. Github SSO should be fairly easy to implement in Angular.

[maoo]

Thanks for volunteering @leandroyabut ! I've assigned the issue to you; happy to test and review, when the PR is avaiable.

[leandroyabut]

No problem, @maoo ! However, I do need some assistance with setting up our GitHub authentication flow. We need to set up OAuth2.0 using an initial GitHub account. I assume we should use this project's primary GitHub account to set it up.

https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/creating-an-oauth-app

Afterwards, we need to securely store the client ID and the client secret.

I'm wondering if this part needs to be its own issue. What do you think?

[maoo]

Hi @leandroyabut !

I created the Oauth App as follows, let me know if you want me to change the callback URL.

Then I've set CLIENT_ID and CLIENT_SECRET as GitHub Action secrets for now, though we'd probably want to have them securely stored into the (Docker Compose) Demo environment; I'll take care of it when we're ready to go live.

In the meantime, I could send them to you via (FINOS) Slack; ping me on help@finos.org and I'll invite you.

Thank you!

[leandroyabut]

Hi everyone, as far as the flow, will we just redirect unauthenticated users to a login page (e.g. /login route)?

[maoo]

@leandroyabut - I'd say so. @DovOps wdyt?

[leandroyabut]

@maoo Can you make another application with the callback URL and homepage URL as our localhost addresses. http://localhost:18093

[maoo]

@maoo Can you make another application with the callback URL and homepage URL as our localhost addresses. http://localhost:18093

Here it comes! 😄

Sending now id and secret via Slack. Let me know if something is missing. TY!

[leandroyabut]

After some testing with this, it seems that Github doesn't allow us to make a POST Request to their access_token endpoint due to CORS. The solution is to create some sort of endpoint on our back end to make this request for us that our front-end can use to both send the auth code received from Github and then receive the access token from that same endpoint as a response.

Attempted flow:

1. Get auth code from Github - SUCCESS
2. Send auth code along with client ID, client secret, and redirect URL as a POST request to access_token endpoint. - FAILED due to CORS.

Proposed flow:

1. Get auth code from Github - SUCCESS
2. Send auth code to backend endpoint - ...
3. Backend sends POST request to Github access_token endpoint. - ...
4. Receive response with the access_token and send back to frontend - ...

We need someone to implement this endpoint in a separate auth microservice. What do you guys think?

[maoo]

Hi @leandroyabut - we already stumbled into CORS issues, which led us to add an ingress module in https://github.com/finos/traderX/tree/main/ingress . Is this something that could help you?