Hacker News Reader

Comment by mamcx | Hacker News Reader

Exist other 2 major things that I have tried to find but is rarely missed:

1- GOOD multi-tenant support.

Without extra weird hoops like with ORY.

How this must be? Just passing a subdomain is all necessary to route and it need to make easy to create/remove tenants as part of MY logic, not need to orchestrate stuff.

2- Use my own tables. (or allow to set FX/new fields)

I appreciate to have automated all the stuff but I have much logic around what is a "user" (and in a recent project, 2 kinds of user in 2 different tables: salesman/customers).

Ideally, this stuff only need to do "SELECT fields_for_auth FROM my_table"

View on HN

One of the Authelia devs here. Authelia actually in 4.27.0 supports matching the user name as a subdomain in a rule, or a group name.

Ideally long term we'll add regex support for usernames/groups in both path's and domains so that people can customize this further.

As a side note, I'd be willing to work specifically with someone wishing to utilize this to improve it. Feel free to reach out on our matrix or discord.

> 2- Use my own tables.

If managing data directly and personally is a requirement for you, then you probably don't want these tools. Part of the reason they exist is to manage user data (passwords, tokens, etc.) correctly and with minimal surprises.

ORY Kratos, as an example, will happily create different conceptual types of users and you can store arbitrary data in those user documents, but it is modified through an API and exposes to you stable IDs against which you can code the rest of your application.

The problem is that this tables are like "foreign" to the db, in a micro-service mindset (the worst anti-pattern to date!).

That is a major complication.

In Django, this solve neatly, because I can point to my own table or easily integrate the ones of Django without much fuss. This turn all this in a non-issue.

Yes, they're foreign to your application's database. That's the point: by using these tools you're buying into a service-oriented architecture.

What you are advocating is to collapse the service-oriented architecture into a "everybody parties on the database" architecture. These tools are very much invested in you not doing that. There already exist user-auth libraries for what you want and run inside your application itself.

> ORY Kratos, as an example, will happily create different conceptual types of users and you can store arbitrary data in those user documents, but it is modified through an API and exposes to you stable IDs against which you can code the rest of your application.

The stable-ID solution was how I handled this when I wrote one of these as an internal tool (guess you'd call it a "microservice") for a startup I worked for back in like 2010. In hindsight I guess I should have pushed to pivot to selling that as our product since we ended up selling the company for barely-pay-back-the-investors money, but who knew? Hahaha.

Also identified permissionable-objects as UUIDs, which let me handle authorization in addition to authentication. Creating a new "permission" object meant asking for one from the service, then you'd receive a UUID, associate that with whatever thing you were applying the permissions to on your end, and tell the service to assign the desired permissions. Then you could just query the permissions for that UUID (which could, potentially, represent a bundle of items, a single item, or permissions to an entire service—how to interpret it was left up to the consuming service) and of course cache them as much as you felt was proper. IIRC there as also a concept of owning-objects so you could let permissions be inherited, then override on a case-by-case basis, plus it'd let you ask which objects belonged to a given collection. IIRC I used that to represent organizations, too, since they were basically the same thing as a permissionable-object container themselves needing to be permissionable.

Not a perfectly-flexible system (billions of items that all need distinct permissions might have eventually forced sharding or something, but luckily we didn't have to worry about that) but it was rock solid for our purposes and made spinning up new services or products sharing login with our main product super-easy.

What is a "stable IDs"?

> GOOD multi-tenant support.

Is this so you can easily private label the application? Or is there some other use case for which multi tenant support is critical?

> Use my own tables. (or allow to set FX/new fields)

I'm not sure what 'FX' is (maybe a typo for 'FK'?).

Do you mean the ability to store arbitrary data on the objects provided by the auth system (even if it is via API like a sibling comment mentions) or are you talking about the ability to create tables or have a foreign key directly into your application's database? Would stable GUIDs solve this for you?

> Or is there some other use case for which multi tenant support is critical?

To support multi tenants in software-as-services. I need to support "company1.app.com, company2.app.com" in my apps.

> Do you mean the ability to store arbitrary data on the objects provided by the auth system...

The thing is that a "user" have different means. I have salesman's, customers, operators, etc.

Them have fields, like email, is_active, personal info, that are critical for the logic of the app.

IDEALLY the auth server manage the security and read only the fields that are needed to operate this (like for send a password reset).

The other fields, triggers, indexes, etc are more important the rest of the time.

And I don't want to use a "will create corrupted integrity for sure, aka: micro services" because I work in the "sync data across dbs" and it ALWAYS will happened if data is not in single transaction.

I have definitely seen folks use the id created by the auth system but nothing else. Everything else keys off the GUID, which should be immutable, and is stored in application specific tables.

The password and username are in the auth system, but everything else stays in control of the application, in one database.

I don't see why you couldn't use that pattern no matter which external auth provider you are using. You'd just give up things like self service registration, but that may be the right choice for your app.

re:multitenant, is keycloak the only good + stable oss path?

Keycloak has a couple of things than can go wrong with multi tenancy especially if you consider using one keycloak realm for each customer after 100 realms keycloak can just become unresponsive and the tokens from the master admin realm become to big. (https://issues.redhat.com/browse/KEYCLOAK-4593)

What would be better than Keycloak then?

Reply on news.ycombinator.com