search

canonical / identity-platform-login-ui

Login UI for the Canonical identity broker and identity provider solution
Apache License 2.0
9 stars 6 forks source link

Login UI requires openfga deployment #221

Closed natalian98 closed 5 months ago

natalian98 commented 5 months ago

Using the latest image, login ui requires openfga deployment in order to work, otherwise it fails to return the allowed identity providers even if AUTHORIZATION_ENABLED=false.

poc-kratos-selfservice-ui-node-1  | 2024-02-01T14:27:46.199Z [login-ui] github.com/canonical/identity-platform-login-ui/pkg/kratos.(*Service).CheckAllowedProvider(0xc000280720, {0xf98500?, 0x1599f00?}, 0xc000150000, 0xc00021aa80)
poc-kratos-selfservice-ui-node-1  | 2024-02-01T14:27:46.199Z [login-ui]     /root/parts/go-build/build/pkg/kratos/service.go:173

To reproduce: Set up a docker environment with kratos, hydra and login ui (for example https://github.com/natalian98/oathkeeper-poc/tree/test-with-httpbin) pinning the login ui version to latest

syncronize-issues-to-jira[bot] commented 5 months ago

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/IAM-671.

This message was autogenerated

nsklikas commented 5 months ago

The docker-compose file on that repo was broken, I had to change this to make it work:

diff --git a/poc/docker-compose.yml b/poc/docker-compose.yml
index bc75717..758ab65 100644
--- a/poc/docker-compose.yml
+++ b/poc/docker-compose.yml
@@ -41,10 +41,11 @@ services:
     networks:
       - intranet
   kratos-selfservice-ui-node:
-    image: ghcr.io/canonical/identity-platform-login-ui:v0.11.3
+    image: ghcr.io/canonical/identity-platform-login-ui:v0.12.0
     environment:
       - KRATOS_PUBLIC_URL=http://kratos:4433/
       - HYDRA_ADMIN_URL=http://hydra:4445/
+      - BASE_URL=http://localhost:4455
       - PORT=4455
       - TRACING_ENABLED=0
       - AUTHORIZATION_ENABLED=0
@@ -108,7 +109,6 @@ services:
       # - "5555:5555" # Port for hydra token user
     command: serve -c /etc/config/hydra/hydra.yml all --dev
     volumes:
-      - ./hydra.yaml:/etc/config/hydra/hydra.yml
       - type: volume
         source: hydra-sqlite
         target: /var/lib/sqlite

I was unable to reproduce the bug, can you add some instructions?

natalian98 commented 5 months ago

Could you test from https://github.com/natalian98/oathkeeper-poc/tree/test-login-ui? There were some changes to the other branch, sorry for that If you go to http://localhost:8080/anything/test, you should get the following screen: image

After clicking on it, a network call gets an error:

image

Logs:

2024-02-02T09:18:27.731Z [login-ui] 2024/02/02 09:18:27 http: panic serving 172.24.0.1:40342: runtime error: invalid memory address or nil pointer dereference
2024-02-02T09:18:27.731Z [login-ui] goroutine 85 [running]:
2024-02-02T09:18:27.731Z [login-ui] net/http.(*conn).serve.func1()
2024-02-02T09:18:27.731Z [login-ui]     /snap/go/10489/src/net/http/server.go:1868 +0xb9
2024-02-02T09:18:27.731Z [login-ui] panic({0xc2fd40?, 0x154e000?})
2024-02-02T09:18:27.731Z [login-ui]     /snap/go/10489/src/runtime/panic.go:920 +0x270
2024-02-02T09:18:27.731Z [login-ui] github.com/canonical/identity-platform-login-ui/pkg/kratos.(*Service).CheckAllowedProvider(0xc00007ed80, {0xf98500?, 0x1599f00?}, 0xc0004ef200, 0xc00009ae10)
2024-02-02T09:18:27.731Z [login-ui]     /root/parts/go-build/build/pkg/kratos/service.go:173 +0xf8
2024-02-02T09:18:27.731Z [login-ui] github.com/canonical/identity-platform-login-ui/pkg/kratos.(*API).handleUpdateFlow(0xc00020fa70, {0x7f22412aa0d0, 0xc0000af2c0}, 0xc00041c700)
2024-02-02T09:18:27.731Z [login-ui]     /root/parts/go-build/build/pkg/kratos/handlers.go:142 +0x2c6
2024-02-02T09:18:27.731Z [login-ui] net/http.HandlerFunc.ServeHTTP(0xc27de0?, {0x7f22412aa0d0?, 0xc0000af2c0?}, 0xc0000e71a5?)
2024-02-02T09:18:27.731Z [login-ui]     /snap/go/10489/src/net/http/server.go:2136 +0x29
2024-02-02T09:18:27.731Z [login-ui] github.com/go-chi/chi/v5.(*Mux).routeHTTP(0xc00007ed20, {0x7f22412aa0d0, 0xc0000af2c0}, 0xc00041c700)
2024-02-02T09:18:27.731Z [login-ui]     /root/go/pkg/mod/github.com/go-chi/chi/v5@v5.0.10/mux.go:444 +0x2b4
2024-02-02T09:18:27.731Z [login-ui] net/http.HandlerFunc.ServeHTTP(0xc00041c600?, {0x7f22412aa0d0?, 0xc0000af2c0?}, 0xb3304e?)
2024-02-02T09:18:27.731Z [login-ui]     /snap/go/10489/src/net/http/server.go:2136 +0x29
2024-02-02T09:18:27.731Z [login-ui] github.com/canonical/identity-platform-login-ui/pkg/web.NewRouter.RequestLogger.func3.1({0x7f22412aa0d0, 0xc0000af240}, 0xc00041c600)
2024-02-02T09:18:27.731Z [login-ui]     /root/go/pkg/mod/github.com/go-chi/chi/v5@v5.0.10/middleware/logger.go:54 +0x16d
2024-02-02T09:18:27.731Z [login-ui] net/http.HandlerFunc.ServeHTTP(0xc0001f5cc0?, {0x7f22412aa0d0?, 0xc0000af240?}, 0xc00041c600?)
2024-02-02T09:18:27.731Z [login-ui]     /snap/go/10489/src/net/http/server.go:2136 +0x29
2024-02-02T09:18:27.731Z [login-ui] github.com/go-chi/cors.(*Cors).Handler-fm.(*Cors).Handler.func1({0x7f22412aa0d0, 0xc0000af240}, 0xc00041c600)
2024-02-02T09:18:27.731Z [login-ui]     /root/go/pkg/mod/github.com/go-chi/cors@v1.2.1/cors.go:228 +0x17e
2024-02-02T09:18:27.731Z [login-ui] net/http.HandlerFunc.ServeHTTP(0xf97a08?, {0x7f22412aa0d0?, 0xc0000af240?}, 0x1?)
2024-02-02T09:18:27.731Z [login-ui]     /snap/go/10489/src/net/http/server.go:2136 +0x29
2024-02-02T09:18:27.731Z [login-ui] github.com/canonical/identity-platform-login-ui/pkg/web.NewRouter.(*Middleware).ResponseTime.func2.1({0xf97a08?, 0xc0000a59e0?}, 0xc00041c600)
2024-02-02T09:18:27.731Z [login-ui]     /root/parts/go-build/build/internal/monitoring/middlewares.go:35 +0xb4
2024-02-02T09:18:27.731Z [login-ui] net/http.HandlerFunc.ServeHTTP(0xf98538?, {0xf97a08?, 0xc0000a59e0?}, 0xf8cb50?)
2024-02-02T09:18:27.731Z [login-ui]     /snap/go/10489/src/net/http/server.go:2136 +0x29
2024-02-02T09:18:27.731Z [login-ui] github.com/go-chi/chi/v5/middleware.RequestID.func1({0xf97a08, 0xc0000a59e0}, 0xc00041c500)
2024-02-02T09:18:27.731Z [login-ui]     /root/go/pkg/mod/github.com/go-chi/chi/v5@v5.0.10/middleware/request_id.go:76 +0x21c
2024-02-02T09:18:27.731Z [login-ui] net/http.HandlerFunc.ServeHTTP(0xf98538?, {0xf97a08?, 0xc0000a59e0?}, 0x154e7c0?)
2024-02-02T09:18:27.731Z [login-ui]     /snap/go/10489/src/net/http/server.go:2136 +0x29
2024-02-02T09:18:27.731Z [login-ui] github.com/go-chi/chi/v5.(*Mux).ServeHTTP(0xc00007ed20, {0xf97a08, 0xc0000a59e0}, 0xc00041c400)
2024-02-02T09:18:27.731Z [login-ui]     /root/go/pkg/mod/github.com/go-chi/chi/v5@v5.0.10/mux.go:90 +0x315
2024-02-02T09:18:27.731Z [login-ui] go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp.(*middleware).serveHTTP(0xc000234000, {0xf965f8?, 0xc00037a0e0}, 0xc00041c300, {0xf90220, 0xc00007ed20})
2024-02-02T09:18:27.731Z [login-ui]     /root/go/pkg/mod/go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp@v0.45.0/handler.go:217 +0x1202
2024-02-02T09:18:27.731Z [login-ui] go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp.NewMiddleware.func1.1({0xf965f8?, 0xc00037a0e0?}, 0xc00045dac0?)
2024-02-02T09:18:27.731Z [login-ui]     /root/go/pkg/mod/go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp@v0.45.0/handler.go:81 +0x35
2024-02-02T09:18:27.731Z [login-ui] net/http.HandlerFunc.ServeHTTP(0x410745?, {0xf965f8?, 0xc00037a0e0?}, 0xc00037a001?)
2024-02-02T09:18:27.731Z [login-ui]     /snap/go/10489/src/net/http/server.go:2136 +0x29
2024-02-02T09:18:27.731Z [login-ui] net/http.serverHandler.ServeHTTP({0xf93e38?}, {0xf965f8?, 0xc00037a0e0?}, 0x6?)
2024-02-02T09:18:27.731Z [login-ui]     /snap/go/10489/src/net/http/server.go:2938 +0x8e
2024-02-02T09:18:27.731Z [login-ui] net/http.(*conn).serve(0xc00048bb90, {0xf98538, 0xc00009a210})
2024-02-02T09:18:27.731Z [login-ui]     /snap/go/10489/src/net/http/server.go:2009 +0x5f4
2024-02-02T09:18:27.731Z [login-ui] created by net/http.(*Server).Serve in goroutine 11
2024-02-02T09:18:27.731Z [login-ui]     /snap/go/10489/src/net/http/server.go:3086 +0x5cb
nsklikas commented 5 months ago

Now it makes sense.

We use the client_name to make the authorization decision. But when you use oathkeeper to log in, there is no client name in the flow because hydra is not involved, thus the null pointer error. The logic for matching IdPs to oathkeeper apps in not implemented.

Having said that, since authorization is disabled you should not get an error. This is a bug, we should check if loginFlow.Oauth2LoginRequest.Client is not null, if it is we make the authorization with and empty string and let the authorization layer handle it.