Skip to content
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 status API server readiness for user authentication #627

Open
1 task
Tracked by #368 ...
snkaupe opened this issue May 10, 2024 · 3 comments
Open
1 task
Tracked by #368 ...

Discuss status API server readiness for user authentication #627

snkaupe opened this issue May 10, 2024 · 3 comments
Assignees
Labels
Ops Issues or pull requests relevant for Team 3: Ops Tooling question Further information is requested status-page

Comments

@snkaupe
Copy link

snkaupe commented May 10, 2024

@joshuai96 mentioned the status API server supporting user authentication. We will need to discuss the details on this and if there are any changes necessary to enable us to implement GitHub as an identity provider.

Definition of Done

  • Any necessary changes to the status API server and/or specification have been identified. Implementing any changes will be a different issue.
@snkaupe snkaupe added question Further information is requested Ops Issues or pull requests relevant for Team 3: Ops Tooling status-page labels May 10, 2024
@snkaupe snkaupe self-assigned this May 10, 2024
@joshuai96
Copy link
Member

The API server does not, per definition, include any kind of user authentication. See:

The API spec does not include either authentication (AuthN) nor authorization (AuthZ) of any kind. The API server MUST be secured by an reverse/auth proxy.

Ref: scs-0402-v1-status-page-openapi-spec-decision.md

This is realized by using Dex IdP and Oathkeeper in SovereignCloudStack/status-page-deployment.

Dex performs OAuth2 with GitHub and supplies an OIDC endpoint.

Oathkeeper secures the API server, by validating the JWT received by Dex and applying rule bases access controll.

Dex requires the frontend to perform an OIDC Auth, like Auth Code Flow. This can be either done manually. See: SovereignCloudStack/status-page-deployment/docs/usage.md#receive-auth-code

Or in the case of the Angular frontend with an client like damienbod/angular-auth-oidc-client.

@snkaupe
Copy link
Author

snkaupe commented May 15, 2024

So, in order to develop and test the login functionality, it will no longer be sufficient to simply start the API server and Angular web application, but instead, we'll need to use the deployment scripts in some kind of environment like kind, correct? Is the simple deployment setup for that purpose ready?

@joshuai96
Copy link
Member

This can be tested against the local kind deployment, the test k3s deployment or the public SCS deployment. Every deployment is set up to handle user auth.

Please refer to the documentation of your desired environment and SovereignCloudStack/status-page-deployment/docs/configuration.md.

I would recommend the k3s test deployment, as it is not used for anything else and can easily discarded. If you want direct cluster access to flush and redeploy, I can set up access for you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Ops Issues or pull requests relevant for Team 3: Ops Tooling question Further information is requested status-page
Projects
Status: Backlog
Development

No branches or pull requests

2 participants