Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Command Side for User Schemas / Objects on Instance Level #7306

Closed
5 tasks done
Tracked by #6433
hifabienne opened this issue Jan 29, 2024 · 3 comments · Fixed by #7416
Closed
5 tasks done
Tracked by #6433

Command Side for User Schemas / Objects on Instance Level #7306

hifabienne opened this issue Jan 29, 2024 · 3 comments · Fixed by #7416
Assignees
Labels
improvement released resources waiting For some reason, this issue will have to wait. This can be a feedback that is being waited for, a de

Comments

@hifabienne
Copy link
Member

hifabienne commented Jan 29, 2024

As a ZITADEL Admin I am able to manage User Schemas through the API, to be able to define how my users objects should look like and how the different types of users can authenticate.

Acceptance Criteria

  • CreateUserSchema: adds a new schema
  • UpdateUserSchema: changes an existing schema.
  • DeactivateUserSchema: moves the schema to a read only state. Users of this schema cannot be updated anymore. Users are still able to log in
  • ReactivateUserSchema: moves the schema state to active
  • DeleteUserSchema: Removes an existing schema. This operation is only allowed if there are no associated users

Open Questions

  • How to handle the permissions? admin/user? Something relating to the permissions we already have internally?

Additional Information

User Schema

  • id: read only unique identifier
  • state: state of the schema
  • type: single word which describes the schema
  • revision: read only version of the schema, each update increases the revision
  • schema: describes the user
  • possibleAuthenticators: defines the possible types of authenticators. this allows creating different user types like human/machine without usage of actions to validate possible authenticators. Removal of an authenticator does not remove the authenticator on a user
    • TODO: move user.isOrgSpecific to here (on username and idp)

permission

Following permissions are allowed r (4), w (2), rw (6)

  • admin: defines the permissions of the admin
  • user: defines the user of the user

oidcClaim / samlMapping

It is needed to define the oidc Claim and saml mapping so ZITADEL knows how to map the user infromations to the oidc / saml responses/tokens

additional formats

  • phone: possibility to add declare phone numbers
  • language: language tag analog to ietf bcp 47
@hifabienne
Copy link
Member Author

@stebenz @eliobischof
Can you please estimate this issue?

@stebenz
Copy link
Collaborator

stebenz commented Jan 30, 2024

Depend on #7308 for DeleteUserSchema
depend on #7314 for possibleAuthenticators

technical estimation:

  • schema events: 1d
  • schema validation: 1d
  • api definition: 1d
  • permission checks: 1d
  • integration tests: 1d
  • command side definitions + unit tests: 1d

@hifabienne hifabienne assigned livio-a and unassigned eliobischof and stebenz Feb 15, 2024
@hifabienne hifabienne added the waiting For some reason, this issue will have to wait. This can be a feedback that is being waited for, a de label Feb 28, 2024
Copy link

🎉 This issue has been resolved in version 2.48.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
improvement released resources waiting For some reason, this issue will have to wait. This can be a feedback that is being waited for, a de
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

4 participants