jr200 / nats-iam-broker

A NATS decentralised auth-callout service to swap thirdparty IdP JWTs for RBAC'd NATS User JWTs
MIT License
12 stars 1 forks source link

Auth Portal integration #1

Closed gedw99 closed 1 month ago

gedw99 commented 2 months ago

https://github.com/authelia/oidc-tester-app might be useful to replace the third party one that is used. I have not tested integration yet.

Also, Authelia provides an auth portal and can pass the token to caddy or other proxies and so on to nats-iam-broker. I have not tested it yet.

Authelia has its own storage system as there is a lot going on in Ted s of workflows and data .

anyways my intention with this issue is to raise the idea of auth portals .

jr200 commented 2 months ago

I used https://oidctest.wsweet.org/ because it was the quickest thing to get up and running - I'm certainly not committed to it. Are you saying theres some oidc workflow(s) that isnt currently working due to some limitations of the mock auth provider I've chosen - and I could avoid this limitation by switching to authelia's oidc tester app? If so, could you let me know whats missing?

I use authentik in my setup. I'm not very familiar with authelia. Are you saying the microservice is currently not compatible with authelia?

Its meant to be quite a simple service which just accepts a JWT token passed in from the nats connect command. I havent understood how authelia portals or authelia's storage system interacts with nats-iam-broker.

Theres certainly scope for expansion of functionality, but I havent quite grasped what the issue is. Could you flesh out your example pls.

Thanks!

gedw99 commented 2 months ago

I used https://oidctest.wsweet.org/ because it was the quickest thing to get up and running - I'm certainly not committed to it. Are you saying theres some oidc workflow(s) that isnt currently working due to some limitations of the mock auth provider I've chosen - and I could avoid this limitation by switching to authelia's oidc tester app? If so, could you let me know whats missing?

Until I test both I cant really give feedback. For now, its just nice to have options, especially ones that we control.

I use authentik in my setup. I'm not very familiar with authelia. Are you saying the microservice is currently not compatible with authelia?

AH that good to know, because I was really curious what one you were using. I will have a look at Authentik.

I have not had a chance with authelia yet. authelia using the Forward Proxy approach and so i am not sure yet how to use that with the microservice.

Its meant to be quite a simple service which just accepts a JWT token passed in from the nats connect command. I havent understood how authelia portals or authelia's storage system interacts with nats-iam-broker.

Forward Proxy Is the "interfacing". I am also lost on how to do it right now.

Theres certainly scope for expansion of functionality, but I havent quite grasped what the issue is. Could you flesh out your example pls.

I think for now I need to try Authentik to get up to where you are first.

If you want add it to the Makefile to make it easier to test.

Thanks!

gedw99 commented 2 months ago

The other one is Pocketbase. It's crazy simple but has many Auth Providers.

https://github.com/pocketbase/pocketbase/tree/master/tools/auth

Its likely quite easy to get that working with NATS.

jr200 commented 2 months ago

As long as the third-party auth provider is OIDC connect compliant, it should work with nats-iam-broker. This means you should be able to plumb in any provider you want: auth0, google, authelia, keycloak, pocketbase.... You only need to pass a non-expired JWT obtained from your third-party auth-provider into the password field of the nats connect command, and the nats-iam-broker microservice should be able to swap that for a nats user JWT.

Its also not clear to me how you would use the forward proxy flow to interface with nats server, or what the benefits of doing this are. But I have quite a specific use-case for nats too...

gedw99 commented 2 months ago

As long as the third-party auth provider is OIDC connect compliant, it should work with nats-iam-broker. This means you should be able to plumb in any provider you want: auth0, google, authelia, keycloak, pocketbase.... You only need to pass a non-expired JWT obtained from your third-party auth-provider into the password field of the nats connect command, and the nats-iam-broker microservice should be able to swap that for a nats user JWT.

Thank you so much. That makes it much clearer and easier to work out things.

Its also not clear to me how you would use the forward proxy flow to interface with nats server, or what the benefits of doing this are. But I have quite a specific use-case for nats too...

I was also not at all sure how to get Authelia's Forward Proxy to work. I am ignoring it for now.

Pocketbase has a ton of Hooks that we can leverage. I need to check if I can get the non-expired JWT passed along. https://github.com/pocketbase/pocketbase/discussions/5339

jr200 commented 2 months ago

I see! Ok then perhaps I need to improve my documentation slightly.

Once you authenticate with your OIDC-compliant auth provider, you'll get back an id_token (this is a short-lived token that will normally expire in ~1h or <24h). This is the jwt you want to use in the nats connect command. Have a look at examples/basic/basic_simulate_login.sh.

JWT_DWHO=`idp_mock_login_public dwho dwho`
test-client \
    -url=${NATS_URL} \
    -creds=${SECRET_STORE}/MINT/user-nobody.creds \
    -jwt $JWT_DWHO \
    -run-test "pubsub basic.public.ZHdobw== hello-from-dwho"

The first line simulates the login process with your chosen oidc provider. When you successfully login, you will get back an id_token JWT. In my example, this jwt is passed to the test-client which does:

nc, err := nats.Connect(
    natsURL,
    nats.UserCredentials(credsFile),
    nats.UserInfo("jwt", idpJwt),
)

Notice the username="jwt", password=idpJwt.

The test-client is a minimal app which simulates what you would do in your real application to connect to nats.

gedw99 commented 2 months ago

Thanks for this . It’s really helpful !!!

You have spent heaps of time on docs in the READE. I am thinking that a few code examples that “ just work “ will be good.

So, I have a passkey system working that’s in golang and does the GUI and backend that I am planning to hook into your nats system.

I found a good OIDC server in golang so we can use that.

Then we have all the bits needed for a full demo that can be in this or another repo .

It’s very light using no frameworks . No blost . That’s kind of the cool thing with Passkeys in that it’s baked in to browsers and OS and Ou just need a bit of code to use it.

I was thinking that we could add it to this repo as a nice and simple example that just works .

gedw99 commented 2 months ago

https://github.com/nats-nui/nui is a decent gui nats that will help devs too btw .

gedw99 commented 2 months ago

https://github.com/zitadel/oidc Is the oidc client and server .

jr200 commented 2 months ago

https://github.com/zitadel/oidc Is the oidc client and server .

Oh I hadn't heard of zitadel, but it does look lightweight. I agree that a more complete example would help. I'm currently working on writing a helm-chart for this microservice, and also getting that to work with vault/openbao.

After that, I'll do a minimal javascript/react example - though I might put that example in a separate repo. Will keep you posted. Thanks for your feedback @gedw99

gedw99 commented 2 months ago

Sounds perfect . I am working on the same too.

Let’s touch’s touch base on where we both end up and work out next steps ..

I am a bit of a fan of mono repos so am doing it that way for now …

jr200 commented 1 month ago

Hi @gedw99, I've put up an example of a react single-page-app to show how the auth flow would integrate with the nats-iam-broker service. Marking this as resolved now.

see: https://github.com/jr200/nats-skeleton-spa