Pyplan has several security options to manage users and their corresponding permissions. Each user can have access to different companies, and have different departments and roles.
¶ User manager
Pyplan has a user manager to manage users, roles and corresponding departments. It is available in the Security options menu under Users.
Within the User Manager section, you have the capability to view a comprehensive list of all users. Moreover, for those endowed with the requisite permissions, the User Manager facilitates the seamless creation or modification of Pyplan user profiles.
¶ User creation
To create a new user you must access the Add user option in User manager
To achieve this, it is imperative to input information into the designated fields, including First Name, Last Name, Email, Username, and Password. Additionally, users have the option to choose settings such as changing the password upon login and enabling multi-factor authentication.
Then you choose, for each company you want to assign to the user, the corresponding role and departments.
¶ Edit users
It is also possible to edit existing users. To do so, select the user to be edited and in the top menu choose the edit user option. It is also possible to change the password by clicking on the change password option.
¶ Roles
A role is a collection of permissions that are assigned to a user within the platform. Roles can be assigned and customized according to the needs of each organization.
Roles are created by accessing the Add role option in the top menu. Then you must select the company to which the role will belong, the name and one of the templates that has a set of default permissions configured, which can then be modified and customized in the Permissions by role option.
¶ Permissions by role
The permissions assigned to each role can be modified from the Permissions by role option. When entering you can see the list of permissions, which are grouped by different aspects of the platform, such as, for example, file manager o interfaces.
When any of the groups are displayed, the permissions are detailed and can be edited for each of the roles in the current company by checking or unchecking the corresponding checkboxes.
These are the default roles and their associated permissions in PyPlan:
| Module | Permission | Administrator | App Administrator | Creator with Public Access | Creator | Explorer | Viewer | Login Only User | Super Administrator |
| Aplications | Create apps | ✓ | ✓ | ✓ | ✓ | ✓ | |||
| Create versions and scenarios | ✓ | ✓ | ✓ | ✓ | ✓ | ||||
| View diagram | ✓ | ✓ | ✓ | ✓ | ✓ | ||||
| Save changes in app in private space | ✓ | ✓ | ✓ | ✓ | ✓ | ||||
| Save changes in Public app | ✓ | ✓ | ✓ | ✓ | |||||
| Set permissions in diagram modules | ✓ | ✓ | ✓ | ||||||
| Interfaces | View interfaces | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |
| Add, modify, or delete interfaces | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |||
| Set interface permissions | ✓ | ✓ | ✓ | ||||||
| File Manager | View File Manager | ✓ | ✓ | ✓ | ✓ | ✓ | |||
| Add, modify, or delete files in private space | ✓ | ✓ | ✓ | ✓ | ✓ | ||||
| Add, modify, or delete files in Public | ✓ | ✓ | ✓ | ✓ | |||||
| Set permissions on files/folders | ✓ | ✓ | ✓ | ||||||
| View other users' folders in the same company | ✓ | ✓ | ✓ | ||||||
| View folders from other companies | ✓ | ||||||||
| External Links (API endpoints and Interface links) | Create, modify, or delete API endpoints or external links to interfaces | ✓ | ✓ | ✓ | ✓ | ✓ | |||
| Workflow | Manage processes | ✓ | ✓ | ✓ | |||||
| Teams | Add, modify, or delete Teams in the same company | ✓ | ✓ | ✓ | |||||
| Departaments | Add, modify, or delete departments in the same company | ✓ | ✓ | ✓ | |||||
| Users | Add users to the same company | ✓ | |||||||
| Modify users in the same company | ✓ | ✓ | |||||||
| Instances | View company instances | ✓ | ✓ | ✓ | |||||
| Deactivate company instances | ✓ | ✓ | ✓ | ||||||
| Roles | Create, modify, or delete roles | ✓ | |||||||
| Companies | Create companies | ✓ | |||||||
| Modify companies | ✓ | ✓ | |||||||
| General Settings | Modify General Settings | ✓ | ✓ | ||||||
| Scheduled Tasks | Create, modify, or delete scheduled tasks | ✓ | ✓ | ✓ | ✓ | ✓ |
¶ Departments
Departments determine permissions on data, e.g. deny access to certain folders in the file manager or to certain interfaces of an application, as well as the hardware specifications of the instances to be used. When opening the department manager, existing departments can be viewed, and new ones can be edited or create.
To create a new department, select the Add department option in the top menu. Then choose the name of the department to be created, the company it corresponds to and the engine definition.
¶ Teams
Teams allow certain users to work in groups, sharing files and applications within a company, only with users who are part of a particular Team. Each team has a folder in the file manager, within the Teams folder, which can only be accessed by users who are part of the team. When you open the Team manager you can see the existing teams in the company. You can add new teams or edit existing ones.
To create a new team, select the Add team option and then choose a name for the new team. You can then add different departments to access permissions to the team, each with its own access level (read-only or read/write).
¶ Companies
In Pyplan, each company offers an isolated environment for the different users of the company to work together, being able to share files and applications. From the company manager you can create new companies and edit existing ones.
When creating a new company you must choose the name and also the name of the folder where all the corresponding company files will be saved.
In addition, when creating a new company, a Pyplan license must be provided for the new company to be activated. This allows the company to be activated for a period of time and for a certain amount of users that are determined by the license.
You can manage preferences for a company by clicking in *Preferences button, having selected a company previously
Below is a list of all configurable preferences allowed by a company. Each preference has a JSON value that is predefined for most preferences.
To enable Single Sign-On (SSO) authentication using SAML, a specific JSON for this configuration must be added as a preference in SAML Configuration.
The JSON has the following structure:
{
"groups": ["Name of Group"],
"definition": {
"service": {
"sp": {
"idp": {
...
},
"single_sign_on_service": {
...
}
}
},
"name": "Company name",
"endpoints": {
...
},
"force_authn": boolean,
"name_id_format": [
...
],
"allow_unsolicited": boolean,
"required_attributes": ["requiredAttr"],
"want_response_signed": boolean,
"name_id_policy_format": "string",
"want_assertions_signed": boolean,
"name_id_format_allow_create": boolean
}
},
"entityid": "string",
"metadata": {
...
},
...
},
"departments": ["departmentCode"],
"main_department": "string"
}
- groups: Defines the role with which the user will be created. You must add the name of an existing role from the list of roles.
- definition: The value of this field is a JSON object containing relevant information such as the company name, the Identity Provider (IdP), metadata required for the connection, and other details defined by Active Directory in the context of SAML integration with a Service Provider (SP).
This JSON may include crucial data to establish the connection between Active Directory and the SP, including precise identification of the company, specific IdP configuration, metadata required for authentication and authorization, as well as any other details necessary to ensure successful integration.
For example, it may contain details such as the IdP's login URL, the public keys needed for SAML token verification, the redirection URL for authentication flow, among others. This data structure provides an efficient means to convey the necessary information to correctly configure the SAML integration between Active Directory and the SP, thereby facilitating interoperability and security in the authentication and authorization process. - departments: Defines the department assigned to the user. This department must exist within the list of departments for the company.
- main_department: Corresponds to the main department defined for resource usage. It must be included in the list of departments; otherwise, it will not be assigned.
If it is necessary to define a default role from the Active Directory, an additional configuration can be added by adding an extra preference in Role Mapping:
In this case, another JSON with the following structure is added:
{
"role": {
"ManagerFromActiveDirectory": "Administrator",
"CustomUserActiveDirectory": "Creator"
},
"department": {
"SalesActiveDirectory": ["pyplan-default", "guest"],
"InvitedActiveDirectory": "guest"
}
}
- role: This will be a JSON where the keys correspond to the role defined by the Active Directory and the value will be the role defined by Pyplan.
- department: Similarly to the previous field, a JSON is defined where the keys are the departments defined in Active Directory and the values will correspond to the departments defined in Pyplan. Note that each key can either be a department in string format or a list of departments.
¶ Grant/Deny access to information
In Pyplan, you can manage access permissions for specific items (like folders, modules, interfaces, etc.) at a department level. For example, departments like Accounting and Human Resources (HR) can have different access settings that determine what they can view or interact within Pyplan.
¶ How it works
You can either allow or deny access to certain items for a department. If an item is in the allowed list, the department can access it. If it’s in the denied list, they cannot. The system will automatically handle conflicts: if something is allowed, it will be removed from the denied list, and vice versa.
Here are a few examples:
Accounting is allowed to access Folder A but denied access to Interface X. This means they can see all the data in Folder A, but cannot view or interact with Interface X.
HR might need access to a specific module for Employee Management. If the module is allowed for HR, it will automatically be removed from any denied lists to avoid confusion.
¶ What you can control
For each department, you can set permissions for the following items:
- Interfaces and Folder Interfaces
- Folders
- Modules
¶ Example scenario 1: Configuring permissions for interfaces
From the Interface Manager, I can select one or more interfaces where I want to modify access permissions, as shown in the following image.
This displays a modal where I can choose to deny access to one or more departments or allow access only to the selected departments. Only one of these options can be chosen at a time. If the interface already has permissions set (whether for access or denied access), these will be overridden, and the latest update will take precedence.
Once the option is selected, the interface will display a padlock icon, indicating that there is a restriction in place.
Similarly, permissions for folders within the interfaces can be restricted in the same way as for interfaces.
¶ Example scenario 2: Configuring permissions in the File manager
The configuration of permissions in the File Manager is similar to that for interfaces, with the difference that I can only select one folder at a time. I navigate to the folder I want to restrict access to and open the options menu shown in the image.
This again displays a modal with the same options as in the Interface Manager.
For this example, I’m configuring that the application "Public App 1" will only be visible to users whose department is Accounting. Any other users from different departments won’t have access to this application or see it in their file space.
It’s important to note that if a user belongs to both the Accounting and Human Resources departments, they will still have access to the application because they belong to the Accounting department, in addition to Human Resources.
¶ Example scenario 3: Configuring permissions for modules
To restrict permissions for diagram modules, proceed by selecting one or more required modules, then right-click on any of the modules to bring up the contextual menu for the module.
As with the previous examples, the same modal will appear, offering the same permission restriction options.
In this example, access to these two modules is denied for users belonging to the Accounting department. When these users enter the diagram, they won’t see the restricted modules.