Hi. I am trying to clarify what "Not supporting mu...
# talk-kratos
j
Hi. I am trying to clarify what "Not supporting multi-tenancy" in the self hosted Kratos means as it can be a bit ambiguous ?
https://www.ory.sh/docs/kratos/guides/multi-tenancy-multitenant
If my app has many unrelated accounts (basically companies) and every account can have many users - Is that considered multi-tenancy in this context ?
w
i would say yes.
kratos has no exposed mechanism for discriminating between tenants. they have an
organization_id
but this value is not exposed for "public" use nor is it expressly obvious how they use it within the ory.sh network. That said, this value can be used to essentially add multi-tenancy to kratos. the how of that implementation is an exercise for the reader.
j
Thanks for the answer. Even without using
organization_id
, what prevents me from adding
account_id
or
org_id
to metadata / user traits to be able to separate between users from different accounts ? I am new to Kratos, and only started to go through the docs now so I might be missing something that may be apparent down the road
w
absolutely nothing. except, keep in mind, you would need something external to set those values as kratos simply would not (without "assistance" ie forking)
also,
metadata_public
and
metadata_admin
are "wild wild west" in that they are not json schema validated. You would need to do that yourself.
but you're talking about traits. another thing to consider, traits are something that users can change.
as well as see them plain-as-day on their session.
i missed that you mentioned "traits"
traits won't work as you would think they would for this purpose.
as they would need to be defined within the identity schema.
and this means that they would be a part of the registration process ie input by the user.
and the flows for settings/profile updates would include those values as parameters open to be changed by the user during a settings-change flow for example.
prolly not desirable when you're talking about a multi-tenant system.
j
and admin metadata ?
w
the downside of the metadata approach is that there's no simple and direct way of updating it.
it would have to be done outside of flows (can be done in a webhook/action) but ONLY registration and settings update.
the users profile can only be modified as a result of those two "actions" or webhooks.
"after profile settings" (not password) and after registration.
the response from those two webhooks can be "parsed" and shoved into the users profile (unfortunately merges are not allowed - it's a full replacement of whatever key it clobbers)
so if the webhook returns an object with
traits
you're hosed.
unless that traits has exactly the right data.
j
I only plan to associate a user to an account once, and that association never changes (i.e. users do not switch accounts)
But if I understand correctly, you're saying it will have to be done after the identity has been created ?
w
how would you handle registration/user creation?
will there be a "ui"?
j
Yes, my own UI
w
ok. that's self-service.
what i'm saying is that the self-service ui, ootb, supports various things like registration, login, settings changes (profile changes) recovery, validation/verification (for email for example) etc
metadata public can be seen by the user (in the users session) but cannot be changed by the user (only via admin api)
the metadata admin can be only seen and updated by the admin api.
j
That is fine, their org id is not a secret
w
so the first step is getting the users into kratos with that value somewhere readable/reliably accessible in the metadata_public.
AND adding hardening/security to the kratos apis 🙂 as they come with zero.
(that's an oathkeeper thing but that's another story)
j
Coming from Hydra, I assumed Kratos was "headless" by default as well
w
it is-ish.
it's headless and "api-driven/based"
but, it defines extremely specific flows for, for example, browser-based interaction
it also defines flows for api-based interactions as well.
would you be using the kratos self-service ui though? if you're using hydra, doesn't that mean you already have some other oauth2 provider?
j
That is for another separate project...
Yeah, I plan to have my own UI
for all the authn flows
w
sorry - if i don't respond its because i'm working 🙂 meetings are starting up
j
Okay, I will continue skimming through the documentation, just wanted to know if it's not a waste of time for the "not supporting multi tenancy" claim. I wasn't sure what that meant in my context. Thank you for your help