User Roles are created at design time but are assigned at runtime as part of the startdard Mendix functionality. There could be rare scenario where user roles are so dynamic that they need to be created at runtime. To handle that, you could build your own roles entity and associate that entity will all other entitities. Your access rules at the entity level would then have XPATH expression that would control the access
My advice is to stick with the userroles created at design time.
As Shekhar mentions, you can create something in runtime, but that will never be as secure as the default implementation. Mendix is a Lowcode platform. The nature of this is that the complex part is abstracted away and you can use the out-of-the-box functionalities. Creating this yourself is breaking the benefit of using a lowcode platform. So even if it is possible, Just.Don't.Do.It.
You can’t create roles at runtime, but you can assign the existing roles you created when building the application to new user you’ve created.
Hope this helps.
As mentioned by others, this is not how you should handle security.
An option, with less impact than on the fly user roles, could be adding booleans for specifics within the normal user roles, unlocking something small for a certain user while using the normal user roles for the big things.
You could do this by making an entity with a description and a boolean value that can be connected to a user entity for example.
But again, if avoidable, please don't do this :P
By doing that, you will weaken the security. Suppose you are creating page access control in runtime, you will be using an Entity (RuntimeSecurity) with Attributes (Boolean) to steer the page access, this Entity has an association with Account. The Page will contain an outer Container with visibility control that is triggered by the Account – RuntimeSecurity/Attribute value of the Boolean. Or you use the same construction to access the data and use XPath to allow access.
The point is that you need to give the role of that user in Design-time a security role that requires all access. That means that whenever a Maker forgets to configure the Runtime security one will have no access when the default value of the Booleans is False, but on the database level, that role does have all access. It requires additional security controls to keep the user away from the data via the database.
The level of complexity you add is tremendous and it will not be easy to maintain the application.
What I could imagine is to create a requirements page that you can use to create a new role in Design-time. But I can’t think of any business reasons why to have such a page as roles are not added that often in apps. And if so, the access to Entities, Logic and GUI should again be designed carefully.
To make a long story short, say no to runtime security and try to make the “must-have” requirement fulfilled by such a role requirement page. Maybe after a while, have the customer see how many requirements came in from the Admins that were not covered by the Product Owner in the Design time.