User Schema #6433
Comments
|
If we use proto defined schema, we could build a validation engine like so: |
|
@fforootd @adlerhurst We just collected all the questions that came to our mind about the user schema discussion. If we missed something or you have some ideas, please drop them here |
|
Just some thoughts and ideas.
|
|
One more thought, should it be possible to define uniqueness of a field? (e.g Email) |
I think this would be a great feature 👍 |
I agree with this, we should choose something ubiquitous to people. Not sure though what fits into this description, I will try to do some research on this subject. For reference I also asked this in discord |
|
Just a thought on email and phone validation: I guess it'd be neat to treat them like any other field, with the addition of being marked as "verifiable". This validation logic (sending a code one way or another that the user then has to enter) could be extendable enough, so that you could implement use cases like:
This validation could be done through actions or the like and would also allow for bringing a custom SMS provider. |
|
Another use case that came to my mind during having a look at zendesks api and i'm unsure if it's already covered: My user should only be able to log in using an IDP. During the registration the flow looks more or less straight forward to me. The users uses the IDP to register and the information is mapped to the user. But how would we handle if there are multiple IDP's and the user must use at least one of them? It gets even more complex if I am an administrator and want to create the users up front because I'm not able to link the users to an IDP then. How would we handle that? |
|
I think using json schema would make a lot of sense. I think, considering how many people are looking to remove first/last name from users, it'd be prudent to get something we can use to make an MVP but designed so we can extend it later with the other desired features. JSON schema already has support for defining validations on properties, including making a list of required fields and setting regex patterns the field values must match. JSON schema allows properties to be defined as strings, numbers, objects, and arrays. I think we could feasibly "extend" JSON schema by defining any additional types we'll need, such as for auth methods. For example, I think we'd also want to "extend" JSON schema by allowing any property to define a "readableBy" and "writableBy", each of which takes an array of strings. Values could be "self", or "admin" to start, but I'd also appreciate the ability to say "role:" or "group:". For example, if I add The trickiest part of all this, imo, is having the default login flow respect the user schema, which I think should be included in some form in the MVP. By making sure there's at most 1 The other tricky part is migrations. I think for MVP we might be able to get away with only migrating Also, we would certainly need a default user schema, which I think could just reproduce the current behavior, thus allowing admins to update Zitadel without anything breaking. The migration should probably get explicit tests though (that is, migrating from the version before this change, to whatever version the test is being ran on). Finally, for MVP I think this could all be done by asking the owner to paste in their schema code. It'll then be ran through a "meta-schema" that'll ensure everything is formatted correctly, and that there's always an email field and some form of auth, only 1 "password" field, only 1 "externalAuth" field, etc. Later on there can be a GUI for all this, but until then I think it can just be hidden away in settings behind a disclaimer not to mess with it unless you know what you're doing and really need to change it. |
|
So here's an example of what the default user schema might look like. I also added a https://gist.github.com/thepaperpilot/04ab18242cc2c434788aa9b7b0825ba3 And for easier access, here's a list of all the things I think would still need to be resolved before this proposed schema design is ready:
|
|
Hi @thepaperpilot |
|
Oh, that's a great idea. I was thinking admins might want to remove one of the password or externalAuth fields if they know they'll never use them, but that was adding a lot of quirkiness to the proposal and it's just as easy for the admin to not have any external IDPs or disable registration via password. Removing those fields from the admin configurable part of the schema simplifies a lot of things. |
|
hi @thepaperpilot sorry i had no headspace left the last two week, i hope it gets better next week. |
Is it possible to re-consider that email must be a mandatory field? A lot of online businesses now uses phone number only, and some web3 applications use self-sovereign identity instead (self-sovereign identity = user wallet's address) I suggest:
|
|
Instead of adding DDLs to ZITADEL I propose an approach which heavily relies on the use of actions and divides data required for authN and additional data. I'm unsure if it is possible to solve all the problems of users using a DDL. My questions are:
Let's consider the following:
Idea:
Definitionmessage User {
// as is, snowflake id
string user_id = 1;
// Information for zitadel to contact the user, possibly related to user_identifiers.
// and if defined to use in authenticators
// Used for emails/sms sent to the user
optional Contact contact = 2;
// multi factors
repeated Authenticator authenticators = 3;
// Data not relevant for authN
optional Profile profile = 4;
}
// stored information inside zitadel
message Authenticator {
oneof authenticator {
// password stored information inside zitadel
Password password = 1;
// passkeys from other devices and universal second factors (u2f)
WebAuthNKey web_auth_n_key = 2;
// one time password
// SMS and email
OneTimePassword otp = 3;
// time based one time password
// authenticator app
TimeBasedOneTimePassword totp = 4;
// keys currently used for machine users
JWT_Profile_Key jwt_profile_key = 5;
// like google login, sign in with apple, ...
IdentityProvider identity_providers = 6;
// if people forget their passwords
string recovery_code = 7;
// can be defined via API calls, there are no computed login_names anymore.
// ZITADEL ensures that each login_name is unique on an instance.
string login_name = 8;
}
}
// DISCUSS: when should be defined which hashing algorithm and config must be used
message Password {
string password = 1;
Time change_date = 2;
}
message OneTimePassword {
oneof provider {
SMSOneTimePassword sms = 1;
EmailOneTimePassword email = 2;
}
}
message SMSOneTimePassword{
oneof provider {
// uses the phone defined in user.contact.phone
bool use_contact = 1;
// analog https://github.com/zitadel/zitadel/blob/ab79855cf059af55e27506b29dfec580751ee2aa/proto/zitadel/user/v2beta/phone.proto#L12
// if this phone is used it's only used for otp
Phone phone = 2;
}
}
message EmailOneTimePassword{
oneof provider {
// uses the email defined in user.contact.email
bool use_contact = 1;
// analog https://github.com/zitadel/zitadel/blob/ab79855cf059af55e27506b29dfec580751ee2aa/proto/zitadel/user/v2beta/email.proto#L12
// if this email is used it's only used for otp
Email email = 2;
}
}
// Information about totp not relevant for the discussion
message TimeBasedOneTimePassword {}
// Information about jwt profile key not relevant for the discussion
message JWT_Profile_Key {}
// Information about web authn key not relevant for the discussion
message WebAuthNKey {}
message Contact {
// email is unchanged as it can be part of the login process, but it is optional now as it's not always required
// It's used to contact the user, e.g. for init or password changed notification
// analog https://github.com/zitadel/zitadel/blob/ab79855cf059af55e27506b29dfec580751ee2aa/proto/zitadel/user/v2beta/email.proto#L12
optional Email email = 1;
// phone is unchanged as it can be used as part of the login process, but it is optional now as it's not always required
// It's used to contact the user, e.g. for init or password changed notification
// analog https://github.com/zitadel/zitadel/blob/ab79855cf059af55e27506b29dfec580751ee2aa/proto/zitadel/user/v2beta/phone.proto#L12
optional Phone phone = 2;
}
message Profile {
// analog the type of protobuf any
string type = 1;
// Data the end user user is allowed to read and manipulate (e.g. first name, last name), it can be seen by org and instance admins
// the user is not allowed to add/remove fields
optional Any self_managed = 2;
// Data can be read by the user, data can be manipulated and read by user manager and read by admins
optional Any managed = 3;
// Data can NOT be read by the user, data can be manipulated and read by user manager and read by admins
optional Any internal = 4;
}
/*
examples of profiles:
{
"type": "zitadel.com/api/user.human.v1",
"selfManaged": {
"@type": "zitadel.com/api/user.human.v1",
"firstName": "adler"
"lastName": "hurst"
}
"managed": {
"@type": "org.com/api/employee.external.v1"
"employeeId": "123"
}
},
{
"type": "zitadel.com/api/user.machine.v1",
"selfManaged": {}
"managed": {
"@type": "zitadel.com/api/user.machine.v1"
"name": "machine",
"description":
}
}
*/
// Is a separate sub resource of users analog sessions. Long lived session in the name of a user.
message PersonalAccessToken {
string id = 1;
string user_id = 2;
}Pro's
Con's
Edits
|
|
@thepaperpilot @pr0gr8mm3r @Lan-Phan if you have some time would be cool to get your feedback or questions on my proposal above :) |
|
That idea looks good to me! It sounds easier to implement, solves the issues I left to be worked out, and would already have an interface in the console. |
|
I would strongly recommend to add
I wouldn't do anything related to validations or structure data, let application level code (actions included) to add such concern, Zitadel itself should treat the information as a bag of traits. |
|
About UserIdentifiers, I would not allow to bind information to the Profile, far too often programmers want to reuse data at the cost of future management, and in IAM, at the cost of a simple mistake causing a security problem. Identity is a extremely tricky situation, the anti-pattern I see is that Make such fields part of the Really tricky if you intertwine Contact information with Authentication information that "becomes" identity to for that reason:
Totally valid! Contact Info != Identity Just copy info at the app-level, and avoid intertwining such data :2cents: |
|
thanks for the feedbacks :) It looks like we are not too far off with this proposal I think internal is definitely worth thinking about. I add it to the proposal. the contact infos are used on different authenticators that's why i split it. The use cases I thought of were the following (there are definitely more to consider):
Because there are workflows which are not related to an authenticator like the init I think it would be misleading if we set them on the authenticators. I agree shared contact information would break uniqueness. I add a comment to the bind's and will discuss it internally tomorrow and add an additional comment. |
|
To overall idea looks great, I just have a single comment:
My experience is that
|
|
@adlerhurst , your idea looks great. I have only 1 concern relating to the number of emails and phones which user have maybe more than 1, so that I suggest to change a little bit:
Changing 1 email / phone to a list of emails / phones will make Zitadel more complex, but I think it's worth for us to do that because normally 1 online user have multiple contacts for now. |
|
@muhlemmer I prefer Any because then the clients have the possibility to check the type of the field. for example if you add a new version of the value the client is able to type switch, which is more difficult with other well known types. Or am I missing something? We should consider a new role which is allowed to change the type. @Lan-Phan That sounds like a good idea. What would you expect to happen if ZITADEL sends a notification? should it be sent to all emails/phones or only to one? Im asking because if it should be sent only to one then ZITADEL must know the preferred one. |
|
This is a long thread, and hard to follow. But I have 1 question that has arisen from the previous comment. Is the UserID not currently a unique and crptographically secure randomly generated value? It is my opinion that PII should never be used as an identifer as a user may change those things. |
|
hi @stephenandary Thanks for the feedback, I totally agree that it's hard to follow, that's why i tried another way for the actions discussion ;-) I think there is a differentiation between the technical ID and "user facing" ID. The technical ID will never change and is generated by zitadel. The id @buehler is talking about is the identifier the user enters during login, currently called login name. |
Understood, thanks for the clarification. The actions conversation is also a little unwieldy lol. Maybe a future attempt at this could use a top level issue with nested sub-issue links. |
Thanks for the input i keep it in mind for the next bigger discussion :) |
User schemaCurrently users are not customizable, if a field is not needed but required it must be filled. Additionally it's currently not possible to define which fields are allowed to be managed by a user and which by an admin. Because of these limitations we propose the following changes to the user schema. And secondly we need to adjust the user to the session API to improve developer experience. RequirementsFunctional
Nonfunctional
Use cases
ProposalThe goal is to provide a minimal user object which is easily extendable. User object
Authenticators fieldEverything that authenticates a user. Authenticators can be manipulated by the users themselves.
Traits fieldThe type of the user must match an existing schema. The schema is used validate the provided fields and also allows validation based on JSON Schema Validation. User methods
User schemaThe user schema is based on JSON schema. ZITADEL adds additional annotations to instances: permissionFollowing permissions are allowed r (4), w (2), rw (6)
oidcClaimAllows to map claims if zitadel is the provider. IDP specific configuration can be handeled on IDP configuration. specifies which OIDC claims the field is mapped to. The claims are validated during write of user schema to verify that types of standart claims can be casted correctly. If casting still fails the claim remains empty if types cannot be casted during token creation. Non standard claims are allowed, type casting is not possible without actions. To complement the token with more complex claims caluculation than set, actions are used. It's possible to map all fields to the token, permissions are ignored. An action can be implemented to fulfill this use case. The annotation is a simple string field, the value works analog to json path. example: "firstName": {
"type": "string",
"oidcClaim": "profile.first_name"
},The above schema would create the following token: {
"sub": "...",
"profile": {
"first_name": "provided first name"
},
"iat": 1516239022
}samlAttributeAllows to map attributes if zitadel is the provider. IDP specific configuration can be handeled on IDP configuration. Specifies which SAML attributes the field is mapped to. The attributes are validated during write of user schema to verify that types of standart attributes can be casted correctly. If casting still fails the attributes remains empty if types cannot be casted during token creation. Non standard attributes are allowed, type casting is not possible without actions. To complement the token with more complex attributes caluculation than set, actions are used. It's possible to map all fields to the token, permissions are ignored. An action can be implemented to fulfill this use case. The annotation describes a [SAML Attribute] as described in chapter 8 SAML Attribute Profiles of the SAML specification The annotation is an object containing the following fields:
example: "lastName": {
"type": "string",
"samlAttribute": {
"name": "urn:oid:2.5.4.42",
"nameFormat": "urn:oasis:names:tc:SAML:2.0:attrname-format:basic",
"friendlyName": "givenName"
}
},The above schema would create the following attribute: <saml:Attribute
xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
Name="urn:oid:2.5.4.42" FriendlyName="givenName">
</saml:Attribute>additional formats
fields of user schema
User schemas can be managed on instance and org level. For the beginning we start on instance level and later add schemas to org level (seperate issue for org level). In the future it will be possible to configure which schema is allowed on organizations. (add issue) Every time a schema is updated the revision of the user schema is increased. User schema methods
Additional informationFollowing use cases will work with action:
Permissions vs. predefined fieldspredefined fields
annotations
following behaviour is expected:
additionalProperties annotation“additionalProperties” is set to false by default, if set to true all sent fields are stored, setting the field to true disables partial updates API call order of executionThe schema is validated on each manipulation of the user object. Actions are not allowed to overrule schema validations, so the schema validation is executed after the action. Token creation order of executionThe definition of claims/metadata mapping is executed before the action is executed. Uploading avatarsIt's possible to store byte arrays on a user, but it's not recommended to store picutes on the user object, only the URLs of assets should be stored on the user. If a user wants to upload an avatar, the avatar fist has to be stored and afterwards the manipulation on the user with the updated URL. Email/phone validation in schemaZITADEL will not provide the logic to send out verification notifications at the beginning. Additional changesDefaultInstanceThe user schemas will be added to the default instance configuration. IDPTODO: (adlerhurst) unsure about the outcome of the discussion, do we need an attribute/claim mapping on idp? Allow custom attribute / claim mapping per idp. Validation with current behaviourTODO MigrationTODO Projection exampleevents1 user.schema.added 1 {hodor: string} user projection1 build schema Human schema example{
"$schema": "https://zitadel.com/user/human",
"type": "object",
"properties": {
"profile": {
"type": "object",
"required": true,
"properties": {
"givenName": {
"type": "string",
"required": true,
"maxLength": 200
},
"familyName": {
"type": "string",
"required": true,
"maxLength": 200
},
"nickName": {
"type": "string",
"maxLength": 200
},
"displayName": {
"type": "string",
"maxLength": 200
},
"preferredLanguage": {
"type": "language"
},
"gender": {
"type": "string",
"enum": ["female", "male", "diverse"]
},
"avatarUrl": {
"type": "string",
"format": "uri"
}
}
},
"email": {
"type": "object",
"required": true,
"properties": {
"email": {
"type": "string",
"format": "email",
"maxLength": 200,
"required": true
},
"isVerified": {
"type": "boolean"
}
}
},
"phone": {
"type": "object",
"required": true,
"properties": {
"phone": {
"type": "string",
"format": "phone",
"maxLength": 200,
"required": true
},
"isVerified": {
"type": "boolean"
}
}
},
"metadata": {
"type": "array",
"items": {
"key": {
"type": "string",
"maxLength": 200
},
"value": {
"type": "string",
"maxLength": 500000
}
},
"required": [
"key",
"value"
]
}
}
}Machine schema example{
"$schema": "https://zitadel.com/user/machine",
"type": "object",
"properties": {
"name": {
"type": "string",
"required": true
},
"description": {
"type": "string"
}
}
}Edits
|
|
I strongly recommend reconsidering the decision to emulate Okta's approach. From an IT perspective, this strategy introduces significant complexities and potential risks. The overlap of developer and IT responsibilities in managing user data, coupled with the necessity to meticulously prefix fields, elevates the risk of inadvertently exposing sensitive information. That approach also imposes the responsibility of a Schema Registry onto your team. Ideally, application developers should manage this complexity with dedicated Schema Registry tools. Additionally, emulating Okta might necessitate the development of Data Migration Tools, adding to the burden. Overall, this path seems to involve considerable challenges and potential pitfalls that could be avoided with a different approach. Ory did an amazing job by moving into traits and metadata as an improvement to Okta. Clerk recently added Metadata as well that would be closer to what I would suggest to do: type Traits map[string]interface{}
type User struct {
Type string
PublicTraits Traits // or Traits
PrivateTraits Traits // or ManagedTraits
UnsafeTraits Traits // or InternalTraits
}Having a type field or a similar mechanism can greatly enhance the overall identity management process. It enables efficient handling of various user types, and simple enough as a |
|
Hi @yordis thanks for your feedback :) i have some additional questions.
I see your concerns. The idea with the visibility field was that the schema is self describing. If we predefine fields you need to know about the behavior of the fields.
So you would not provide a schema at all?
If organizations migrate from okta to zitadel we need to provide a migration path anyways do i understand something wrong? You basically describe two concerns the complexity of the product by adding schemas to it and user errors based on the visibility field did i miss something?
Thanks for the example. You would also allow different user types but predefine the fields for accessibility. We will consider this approach. Zitadel can use schemas for its default models, unified validation of input and zitadel has the possibility to render user fields dynamically |
Not so simple, "self-describing" is extremely difficult. Linguistics requires context to make sense of data:
You could even argue that some cultures would never call Veterinarian doctors 🤷🏻
It's probably extremely clear, as long we weren't talking about my health while we were at the vet either... Tricky, IAM systems like Zitadel will sit at such a high and out-of-context scope that such simple decision-making becomes difficult. Combine it with high risk, and you can comprehend why I am pushing you back.
Precisely,
That is also why it is crucial to pick the battles carefully. I am not saying the Okta route will not work, but why do you need fancy schema GUI components when a simple JSON blob shown to the user in a text field will do it just fine? Look at Auth0 and The Console is extremely valuable, but we barely live in it. We build IT automation tools around it (use Rippling, for example) or Products that have more control over the UX (accounts.google.com), and so on ... So, what do you want to get out of the Console precisely?
I was talking about the fact that Okta (and Ory to some extent) have to build migration tools inside them to deal with breaking changes between schemas, among many unknown unknowns.
Two major concerns,
|
|
Side note, Actions could map the traits to OpenID Connect Standard Claims; you do not need to create specialized schemas such as Contact/Profile. This is where I still do not know how I feel about it, my gut feeling says "do not do anything special", my product gut feeling says "add a profile field that is OpenID Connect Claims specific" I can not make up my mind about it. Actions should be able to map these claims regardless, so the tricky bit is simplify the 80/20 rule. |
|
hi @yordis sorry for the late reply and the patience with me 😄 I will give feedback and update the concept on friday :) |
|
hi @yordis sorry for the late reply, we had a lot of internal discussions about the permission model and i think i changed my opinion more often than there are days in between my last answer and now 😅 I want to address your main concerns: Visibility Field vs. Specialized Trait FieldsThe biggest pro we can see on specialized trait fields is permission enforcement by design. And our main concerns are the following:
The current concept describes visibility fields which are not logical thats why we made a step back and thought about how this is solved in IT in general and we came up with UNIX file system permissions. It uses inheritance, does not impact folder structures and still allows complex permission models and it's widely understood in IT. These are the main pro's in it from our perspective:
As we don't use executable (1) and don't have group access at the moment we propose the following: permission annotation which consists of two fields at the beginning (admin, user) and the following values can be set on these fields: write, read, readwrite. This annotation is easy to validate that each field has a defined permission either from the field spec or inheritance from the parent fields. a schema could look the following: {
"$schema": "https://zitadel.com/user/permission-example",
"type": "object",
// allows the admin to read and write on each field by default
// user cannot see any fields by default
"permission": {
"admin": "rw"
},
"properties": {
"profile": {
"type": "object",
// admin is only allowd to read the field but not update
// user is allowed to manipulate and read the fields
"permission": {
"admin": "r",
"user": "rw"
},
"properties": {
"firstName": {
"type": "string"
},
"lastName": {
"type": "string"
},
"nickName": {
"type": "string"
},
"DisplayName": {
"type": "string"
},
"preferredLanguage": {
"type": "language"
},
"gender": {
"type": "string"
},
"avatarUrl": {
"type": "string"
},
}
},
"password": {
// admin is only allowed to set the password
// user is allowed to read and write the password
"permission": {
"admin": "w",
"user": "rw"
},
"type": "password"
}
}
}Zitadel Schemas vs. Action/App-Level/"Unstructured" DataWe will allow the "additionalProperties"-annotation which allows you to define a schema where only defined fields are validated. The following example allows as many fields as you want and verifies that the username field is set {
"$schema": "https://zitadel.com/user/additional-props-example",
"type": "object",
"additionalProperties": true,
"properties": {
"username": {
"type": "string",
"required": true
}
}
}We are happy to discuss if you have any concerns :) |
|
Taking Unix as a reference is not good, and it is easy to misguide yourself. I said that because the access pattern in a file system (API) is drastically different from Zitadel or IAM Systems. Think about the Roles of your system, their access patterns, and how the permissions are supposed to look around the use cases for the given Roles. That is critical! Are the permission's roles static or dynamic? How will the whole management of the roles and the schema work if they are dynamic? Is your target audience enterprise customers? If so, could you tell me the precise use cases you see from them? If they are static, well: The whole permission situation is required (making assumptions here) because you want an untrusted role (end-user) to read and write its data, and you want APIs that avoid making a mistake around such data, where you do not accidentally expose For example, https://clerk.com/docs/users/metadata#user-metadata (my apologies that I keep mentioning your competitors; I am honestly trying to help here and make sure you succeed) Notice how they phrase things in the docs; I like to believe it is not accidental: The keywords Technically, this situation wouldn't be There is no right or wrong here, just trade-offs and complexity. As with anything in software, It Depends ™️, what are roles, and use cases per role. I would finally say that Enterprise will always complicate things, which is fine; give them the ability to do so, but isolate the problems to them at the very least. Please keep it simple for the rest of us! |
|
First of all, providing examples is nothing you have to apologize for, we are thankful for that, it helps through the design process to analyze existing solutions ;-)
Maybe it makes sense to describe my mental model first: folder == object, file == field For me it's not that different. Both are a rooted trees, don't care about the payload of the file/field. And the schema is enforced on the file system by the folder structure.
For me it would make sense to simplify the permission model to a single user permission which can be assigned to multiple roles. There are still use cases like manipulating authenticators which still requires a permission model for zitadel.
How ZITADEL will handle permissions is currently discussed here. There are multiple target audiences. You can find use cases below.
I totally agree on that and I also agree that you can enforce that by predefined fields, but from a customers perspective I wouldn't understand why I have to break my user model into predefined fields which break my model.
yes me too.
The use case is what you (your app) define, and your use case should not be influenced by the IAM. At least the model of your use case is hardly influenced by the IAM if you take the example above.
I agree to put a proxy before the IAM. If I would implement a proxy this would have to manually map the data to the specific fields, but bugs in the proxy do not prevent access to sensitive data.
For me the enterprise use case is more enforced by the predefined field approach. If you define a schema like following ZITADEL won't enforce any rules and you can use actions or your proxy to load the schema of your joyce to enforce your model: {
"$schema": "https://zitadel.com/user/additional-props-example",
"type": "object",
"additionalProperties": true,
"permissions": {
"admin": "rw",
"user": "rw"
}
}Use casesFirst time user who wants to get an overviewThere is no coding involved. I want to know which fields a user does consist of? My users must provide an address during registration. What happens when I create a user? Changing the behavior of the default register formThere is no coding involved. First name is an optional field and I don't want to show it in the registration form. Changing the behavior of the loginThere is no coding involved. I want to enforce login by an identity provider. Use the APIThis involves docs and user schema. Which fields do I need to provide? How do I define a custom user schema? What possibility do I have. How can I map my user model to ZITADEL? How can I map my permission model to ZITADEL? ZITADEL admin (operations) provides service to developmentClarify borders what's provided. Define the schema both parties can work with. |
|
following changes were applied to the concept
|
|
There's an additional input for the OIDC claim mapping. Since it will be possible to store the user's address, we need to also be able to add annotations for the see https://discord.com/channels/927474939156643850/1205475933847429140 |
|
Hello @adlerhurst , What do you think to allow an array of profiles in User, so that User can store as many profiles as they want? Your schema: My suggestion: |
Hello @hifabienne, sorry if this is not the best place to ask for news about this ^^' Is there any news regarding the uniqueness of the email field ? This would be really much appreciated as even if we prevent the Console management access (https://zitadel.com/docs/guides/solution-scenarios/restrict-console), they could use their token to use the API directly with the proper scope. For instance, Keycloak allow for email uniqueness and I know that on my last company this was a mandatory requirement that Zitadel does not fulfill. We currently don't have a back-end for user management yet, so we currently use the |
|
@Yberion All that needs to be done including progress is in the original post above. Once User schema is fully implemented, you can define you own uniqueness. |
As an administrator I want to be able to define how my users look like. Also I want to be able to define which fields can be edited by administrators and which by the user itself. I want to be able to define which authenticators can be used by which user.
Todos
Additional Information
The migration path looks as follow:
The text was updated successfully, but these errors were encountered: