Advise customer on separating security and business entities - #11824
Advise customer on separating security and business entities#11824MarkvanMents wants to merge 9 commits into
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| The Administrator user role is always created and has the System.Administrator module role by default. The Administrator user role can also manage users of your application as it has all [manageable roles](/refguide/user-roles/#user-management). | ||
|
|
||
| For Free Apps, the user that created the application automatically has this role by default as well so you can use it to manage your users in that environment. | ||
| For Free Apps, the user that created the application automatically also defaults to having the Administrator role so they can use it to manage the users in that environment. |
There was a problem hiding this comment.
🚫 [vale] reported by reviewdog 🐶
[Mendix.ProductNames] Use 'Projects' instead of 'Apps'
There was a problem hiding this comment.
No, 'Free Apps' is the name of the product offering where you run your app in Mendix Cloud without a paid license.
| For Free Apps, the user that created the application automatically also defaults to having the Administrator role so they can use it to manage the users in that environment. | ||
|
|
||
| This role may be helpful in case you have exceeded your user license restriction in which case you can use any user that has this System.Administrator role to sign in to manage your users. | ||
| This role may be helpful if you exceed your user license restriction, as you can sign in as any end-user that has this Administrator user role to manage your end-users. |
There was a problem hiding this comment.
The System.Administrator module role has entity access rights to remove System.Session objects.
However, there is no UI for this (in the System module). There is UI pages for this in the Administration module, which you cannot reach unless you also include the Administration.Administrator module role.
Technically the System.Administrator module role has nothing to do with user management, because that module role does not grant entity access on System.User. Instead it is the Manageable Roles configuration that does that. However, there is no UI for that (in the System module), so in the end it is the combination of having Manageable Roles AND having Administration.Administrator module role that causes you to be able to manage users (and only via Administration.Account usage).
However, the Administration module contains the UI for removing logged in user System.Session objects. So, probably the only way to end up without consistency check errors in Studio Pro is to have all three... Manageable Roles checked, System.Administrator module role and Administration.Administrator module role. These three go together and you have either all of them or none.
There was a problem hiding this comment.
Technically [...] has nothing to do > actually, it has, because having a user role that includes this module role means there is an exception that you can still log in while there are already (license) max sessions active.
Still, all of this only works ('by accident') if you have all 3 together.
There was a problem hiding this comment.
"only via Administration.Account usage" > Because even while having Manageable Roles configured gives you technically the option to create System.User objects, it is still not possible to commit those to the database, because it has both a) validation rule that says password attribute cannot be emtpy and b) sending a change for the password attribute from the client api is rejected.
| * Constraints on widgets in pages should not be used as a measure of security, but can filter out irrelevant data for the context of the page | ||
| * Keep your attributes editable within data views, because if an access rule prohibits write access, your client will display it as non-editable – this way you are aware of the (correct) working of an access rule | ||
| * Do not make attributes determined by the system (like the status of an order) writable | ||
| * If an anonymous user is allowed to create objects, constrain these objects to the owner (an anonymous user is a **System.User** object created on the fly) |
There was a problem hiding this comment.
Link to a place in the docs where it shows how to do xpath id = currentuser?
| * Keep your attributes editable within data views, because if an access rule prohibits write access, your client will display it as non-editable – this way you are aware of the (correct) working of an access rule | ||
| * Do not make attributes determined by the system (like the status of an order) writable | ||
| * If an anonymous user is allowed to create objects, constrain these objects to the owner (an anonymous user is a **System.User** object created on the fly) | ||
| * Do not set a default rule for read-and-write access—this forces you to think about each attribute that is added to an entity |
There was a problem hiding this comment.
This is not a 'rule you set'. This is about the radio button "Default rights for new members" (o)None ( ) Read ( ) Read, Write, where None must be selected. This is also what is taught in class room training, security workshops and CTF stuff, to never use this.
| * Do not set a default rule for read-and-write access—this forces you to think about each attribute that is added to an entity | ||
| * Implement security constraints as entity access rules | ||
| * Do not use constraints on widgets in pages as a security measure, but filter out irrelevant data for the context of the page | ||
| * Keep your attributes editable within data views, because if an access rule prohibits write access, your client will display it as non-editable—this way you are aware of the (correct) working of an access rule |
There was a problem hiding this comment.
Here we need to (can also be todo for after this PR ;-]) add a thing about page variables! They are a really great help to make things more secure: If you have an attribute that you want to closely inspect changes on, then you can make the attribute read only in the access rights, and use a page variable (edit box) on your page for that value, and have it call a microflow. In the microflow, you then get the object (with unchanged attribute value) and separately, e.g. as a string value the new proposed value. Now you can validate the input and compare it to the previous value and decide if the change is allowed, change the actual object and commit it.
| * Disable anonymous access if it has no function within the application | ||
| * Some applications have anonymous access enabled, solely to serve a custom login form—this can be replaced by modifying the default *login.html* within your theme (which will also help the user experience with an improved loading time) | ||
| * Make roles managing other user roles as strict as possible (configured via **User management** within the user role options) | ||
| * Only allow the role of the app's administrator user (default **MxAdmin**) to create the actual administrative accounts (or configure Single Sign On (SSO)) |
There was a problem hiding this comment.
Best practice: Use this Administrator role only for local account management and/or SSO config, do not give it further access rights on your business process data. (This happens a lot where app developers mindlessly check everything readwrite for their business app data, even if there is no UI for it at all.)
Use a separate user role to organize 'god mode' access to business data if needed (fixing things 'in the backend').
| Which users and roles are defined within an application changes, depending on the function of the app. However, there are some key guidelines to keep in mind when validating the user security: | ||
|
|
||
| You can take the following preventative measures: | ||
| * Disable anonymous access if it has no function within the application |
There was a problem hiding this comment.
Link to other place where more best practices for Anonymous are mentioned?
https://docs.mendix.com/refguide/anonymous-users/
By the way, in there it should be mentioned more explicitly to best practice recommend to have a dedicated user role (preferably named "Anonymous") for it, and in modules have explicit Anonymous module roles, and not mixed with existing other module roles (for internal logged in user)
| When deployed to Mendix Cloud, the information about the administrator user name and role is taken into account when using the **Change admin password** button on the environment. After changing the settings in Studio Pro and redeploying the application, a successful admin password change will trigger the creation of a user in the app with the new name and role. | ||
|
|
||
| {{% alert color="info" %}} | ||
| At this point, the application does not automatically remove the user with the previous user name. Removing the old **MxAdmin** account has to be done manually. |
There was a problem hiding this comment.
It's only the old "MxAdmin account" if the previous name was MxAdmin, not if you change it from Banana to Apple later.
| ``` | ||
|
|
||
| Because of this XPath constraint, access defined in the access rule is only applied to orders for which the customer is the current end-user. | ||
| Applying this XPath constraint means the current end-user can only see orders for the customer associated with the current end-user. |
There was a problem hiding this comment.
Maybe?! change/improve wording because ambiguity: 'customer' can be used both as 'customer person' and 'customer company'. In the example here you constrain to the individual person.
A common real life case is of course that you can see orders placed by your customer company (also by other employees at your customer company). But we want to have a simple example here.
Another way to solve the confusion is to explicitly mention that the example we use is of the style of a webshop with individual visitors, not a business thing.
2 participants
No description provided.