Feature Request: Login with Dex button on the /login page

[smitthakkar96]

We tried to follow instructions to enable Dex Oauth with Litmus, and it works great; however, it requires us to open /auth/dex/login to be able to use it. New users unaware of this might attempt to log in normally, which wouldn't work. It would be nice to have a button to log in with Dex on the login itself page when DEX_ENABLED is true. ArgoCD also does something similar. Attached is the screenshot of the login page when keycloack integration is enabled on Argo for inspiration.

[smitthakkar96]

@Saranya-jena @vanshBhatia-A4k9 @ksatchit any plans to support this or are you open to contributions for this issue? I am happy to contribute this. People landing on the Litmus UI login page often get confused about how to log in via Dex unless they have bookmarked the URL.

[vanshBhatia-A4k9]

@Saranya-jena @vanshBhatia-A4k9 @ksatchit any plans to support this or are you open to contributions for this issue? I am happy to contribute this. People landing on the Litmus UI login page often get confused about how to log in via Dex unless they have bookmarked the URL.

Hey @smitthakkar96,
we're always happy to accept contributions from the community, please feel free to take a fork and raise a PR to the master branch. cc: @Saranya-jena

[williamokano]

@vanshBhatia-A4k9 how would you suggest we can fetch this information? Since the Frontend is built and then served statically from nginx, I suppose we can't leverage environment variables directly.

Some apps sometimes have an "capabilites" endpoint in which we can fetch some information. Would that be suitable for the Login page?

sequenceDiagram
    actor Client
    participant LitmusUI
    participant LitmusAuthServer

    Client->>+LitmusUI: /login
    LitmusUI->>+LitmusAuthServer: /capabilities
    LitmusAuthServer->>-LitmusUI: {DEX_ENABLED: false}
    alt Is DexIDP Enabled?
    LitmusUI->>Client: Login Page With DEX button
    else
    LitmusUI->>Client: Login Page
    end
    deactivate LitmusUI

Loading

Otherwise we would have to work with multi builds concept when dex is enabled, which would prevent to add more SSO.

WDYT?

[smitthakkar96]

@Saranya-jena @vanshBhatia-A4k9 could you provide feedback on the approach proposed by @williamokano, our users are getting confused when they land on the login page and don't see option to login with SSO and we would like to see if we can implement this.

[Saranya-jena]

Hi @smitthakkar96 , thanks for sharing the approach. Will review it shortly and reply here.

[smitthakkar96]

@Saranya-jena any updates here?

[kartikaysaxena]

Can I give it a try? I have implemented OAuth protocols earlier.

[prithvi1307]

Hey @kartikaysaxena please go ahead picking this

[DarthBenro008]

Thanks for your time on detailing your approach @williamokano ,
But we can see the endpoints of dex are enabled only when dex is enabled in env vars:

litmus/chaoscenter/authentication/api/main.go

Lines 167 to 169 in f05556a

	if utils.DexEnabled {
	routes.DexRouter(app, applicationService)
	}

I think instead of making another route named /capabilities, a basic approach would be just to curl /dex/login for a status code and render the Login with SSO accordingly.

litmus/chaoscenter/authentication/api/routes/dex_router.go

Lines 11 to 14 in f05556a

	func DexRouter(router *gin.Engine, service services.ApplicationService) {
	router.GET("/dex/login", rest.DexLogin())
	router.GET("/dex/callback", rest.DexCallback(service))
	}

I don't we need a whole new route to fetch this.

cc: @Saranya-jena

[williamokano-dh]

I think it’s a good idea @DarthBenro008 .

when I suggested the capabilities I had way less knowledge about the internals of litmus, I didn’t know, for example, that that it’s the only idp supported at the moment, so I think your idea is great.

[smitthakkar96]

Makes sense though an explicit capabilities endpoint would make it more extensible however approach suggested above would also work no strong opinions :)

[DarthBenro008]

I agree that the approach is not extensible, however my opinion comes strongly from a 'keep it simple' and security standpoint, the con of a route querying an ENV Var sounds like a lot of effort to review that it cannot be manipulated to fetch other details, ofc if the frontend needs more than one variable of such kind in future, we can take the efforts to create another route and ensure it's security.

[smitthakkar96]

@DarthBenro008 I hope you don't mind me asking for some clarification regarding your suggestion. Upon looking the code here, it appears that accessing the /dex/login endpoint triggers the generation of an OAuth JWT Token, followed by a redirect response. My understanding is that this process is only necessary when a user initiates Dex Login and not before. Is there a way to avoid this extra processing when it's not required?

[DarthBenro008]

Always happy to help!, i'd like to understand in what case is this "extra" process not required? At the moment, if you are using Dex with Litmus, you'd need all these endpoints and this is the process flow as per my understanding.

My understanding is that this process is only necessary when a user initiates Dex Login

The only other login method is the normal auth, which doesn't deal with dex?

[smitthakkar96]

I appreciate your prompt response, even over the weekend. Apologies for any confusion in my previous message. To ensure we're aligned, in your comment here, you suggested initiating a call to the /auth/dex/login endpoint as soon as the login page is loaded. If this endpoint returns a successful response, we will display the Dex login button. Have I understood your proposal correctly?

i'd like to understand in what case is this "extra" process not required

Until the user actually interacts with the Dex login button, triggering the logic within /auth/dex/login, which includes generating an OAuth token and initiating a redirect to Dex, seems somewhat redundant since we need to perform logic again when the button is clicked. To decide whether to display the Dex login button, we only need to determine if Dex login functionality is enabled without triggering logic tied to the actual Dex login process. Having said that, is there a way around this?

[DarthBenro008]

Thanks for an elaborate explanation, this does make a lot of sense! A suggestion is to make a POST/(any other than GET) call method instead, if you hit a 405 (method not allowed), the endpoint exists, if you get a 404 (endpoint not found) the endpoint doesn't exists. This way we won't be able to trigger the logic of redirects.

I also personally now think this is a very hacky, but indeed a working solution. 😃

[smitthakkar96]

I am not sure if this has something to do with how Auth Server is configured. The current behaviour is instead of returning 405 METHOD NOT ALLOWED, it returns 401 if I send POST request to Dex Login endpoint. This can be fixed indeed.

{"error":"unauthorized","errorDescription":"The user does not have requested authorization to access this resource"}%

I also explored the possibility of using an OPTIONS request to verify the existence of the Dex login route. However, it appears to return a 204 status code irrespective of the route's existence, which doesn't help in our case.

Going back to your initial concern regarding adding the capabilities endpoint that @williamokano proposed, I believe the effort to ensure it's secure shouldn't be as much given that all settings are loaded at the startup of the auth server, as seen here, we wouldn't need to fetch environment variables repeatedly. Instead, we would leverage the already-loaded settings var, i.e. utils.DexEnabled.

In search of inspiration, I also looked into how other open-source projects have implemented similar functionalities. For instance, ArgoCD exposes certain settings (code) that the frontend utilizes to adjust UI elements dynamically.

As you said, I also personally now think this is very hacky. Let's consider adding a new route, as @williamokano suggested wdyt?

[DarthBenro008]

Thanks for the detailing @smitthakkar96 , i think let's go ahead with the new route.

• ensure to keep the route global, accessible without any oauth middlewares

Would you be taking this up?

[smitthakkar96]

ensure to keep the route global, accessible without any oauth middleware

Sure

Would you be taking this up?

Sure happy to help :)