Hacker News Reader

Comment by SOLAR_FIELDS | Hacker News Reader

When would I want this over a more generic solution like linking to an idp using something like keycloak? The upside is that its network level blocking, but it still requires modifying the application itself same as connecting an idp, correct? The downside of this approach is that it only works for internal access where your end users are on the tailnet

View on HN

> When would I want this over a more generic solution like linking to an idp using something like keycloak

I assume everyone using Tailscale are opting for "simple code and adminstration" instead of "let me pierce NAT and handle Wireguard tunelling myself". On that point of view, "Identity management" is part of "stuff" that Tailscale helps you in the first place. So why not use it as the "Identity management" solution as well?

When you use `tailscale serve`, you get the headers Tailscale-User-Login, Tailscale-User-Name and Tailscale-User-Profile-Pic that identifies who connected thru the tailscale endpoint. https://tailscale.com/kb/1312/serve#identity-headers

On a separete side note, if you had an exposed OpenID Connect service in the first place, you can use it as the Tailscale tailnet auth SSO: https://tailscale.com/kb/1240/sso-custom-oidc

Doesn‘t tailscale force you to bring your own SSO / IdP already?

So it‘s not part of what Tailscale brings, it just adds another layer of indirection between the SSO / IdP you have already and the app, plus requires some custom library integration work, further enhancing lock-in.

If you write internal apps, this is a lot easier to support.

You don't have to think about redirects, sessions, cookies, syncing your users and their roles in TS and Keycloak, maintaining two separate policy files and all that.

The tradeoff you get is lock in to tailscale and no portability. Though I assume that is true about some of the networking features tailscale offers as well.

It’s at the network level. It will block clients from connecting to the destinations on the network. You don’t need to modify any applications at the destination.

Am I misinterpreting like, the entire body of the article?

> For private services inside your tailnet, like internal tools, implementing auth on every app is overkill. That’s why we developed tsnet, a Go library that embeds Tailscale directly in your applications. This lets you see and react to the identity of every user who makes a request to your app. So, authentication is handled…what about authorization?

The article then proceeds to show how to modify an application using tsnet to embed in the application. Which sounds a whole lot like modifying the application. The point might be that it’s more straightforward to do this then gate behind something like keycloak, but fundamentally it still requires modifying the application

Ah yes. This seems to be something new and entirely optional. They’re saying that it might make sense to some to keep both network and application level authorization defined in one place. Personally, I’m with you in just using a normal SSO solution.

Reply on news.ycombinator.com