Thinkwise breidt zijn partnernetwerk uit met system integrator fizor. Het team van fizor onderscheidt zich door branche-overkoepelende expertise.
Leer alles over de Thinkwise model-driven security aanpak
Applicaties die ontwikkeld zijn met het Thinkwise Platform zijn veilig en toekomstbestendig. Wil je alles weten over de Thinkwise modelgedreven security aanpak, lees dan hier het laatste blog van Anne Buit, Principal Software Engineer bij Thinkwise.
*Dit blog is in het Engels.
Delivering value for the business is what drives software development. Stakeholders are mostly interested in the functional aspects of our applications when it comes to delivering this value.
However, non-functional aspects are just as important. Quality aspects described in ISO/IEC 25010 provide a great starting point for identifying which non-functional aspects are important to your business. The application may fail to meet the demands or could harm the business if these aspects are not considered.
The Thinkwise Platform allows developers to quickly build enterprise applications. In doing so, the Thinkwise Platform not only allows the developer to rapidly deliver functionality but also offloads many of the non-functional concerns to the platform. As an illustration of this, the way in which the entire platform is designed to allow applications to survive technological changes comes with an intrinsic boost to portability. The model-driven development approach of the Software Factory IDE of the Thinkwise Platform provides great maintainability. The runtime interpreted API provides compatibility and the consistent UIs provide great usability.
Some of the other quality aspects are slightly more tricky to simply offload to the platform. While the runtime components are optimized for maximum performance efficiency, the developer also plays an important role in making the right decisions regarding performance. Furthermore, the underlying infrastructure requires alignment as well.
Important security aspects
Another aspect that is difficult to pin down to a sole responsibility is security. Let me explain this in more detail.
Applications built using the Thinkwise Platform may only be accessed by an authenticated user. The process of authentication is fully managed by the Thinkwise Platform.
Developers and administrators can always safely assume that a user is properly authenticated.
Administrators configure user accounts in the Intelligent Application Manager, the management tool for production environments built using the Thinkwise Platform.
There are various supported authentication types. Most types rely on external user stores to verify the user:
- Windows Active Directory
- Azure Active Directory
- Accounts managed by the database.
Mechanisms such as SSPI, Kerberos and OpenID are used by the runtime components to ensure this is done securely. Single sign-on is supported out-of-the-box.
The Intelligent Application Manager also allows administrators to create local accounts. These accounts are fully managed by the Thinkwise Platform. Often created as service accounts and to grant external parties access to the systems, these accounts are password protected using modern algorithms. Password policies, multi-factor authentication, expiry policies, and brute-force protection is available for these accounts.
It is noteworthy that the Thinkwise Platform can also act as an OpenID provider, allowing 3rd party applications to have the user identify themselves using the account in the Intelligent Application Manager.
The platform uses Role-Based Access Control to grant users access to different features of the developed application.
By default, a user will not be able to access any application. An administrator must grant roles to user accounts to allow them to access applications.
Roles are a part of the application model. They are coarse-grained bundles of rights on certain model objects. A single role is designed to fully support a certain business activity within the system that can be granted or revoked without side effects. For instance, you can have a role Approve sales invoices. To read more about roles, click here.
The developers pre-configure these roles for the application as part of the development process. After all, the developers know exactly which parts of the model are developed to support specific business activity. The role is composed by the developer by granting fine-grained CRUD settings on entities, execution on operations and access to UI functions and processes.
Furthermore, data filters can be configured for a role that limits the data available to the user. This can be in a static manner (limit Sales invoices to only those with status draft) or in a dynamic manner (limit Sales invoices to only those assigned to the current user).
The Software Factory ensures each individual role is a consistent bundle of model objects. For example, the menu item Approve sales invoices may not be granted to the role while the Sales invoice entity has not been authorized to the role. To achieve this, roles are not limited to CRUD rights on data entities but include rights on UI model objects and process model objects as well. Validations assist the developer in configuring a consistent, secure and powerful set of roles.
The runtime components of the Thinkwise Platform bring an application to life. They load the customer-specific application models and initialize themselves accordingly. These runtime components are provided by Thinkwise and are kept up-to-date and are even replaced as technologies advance.
When a user accesses the application, the runtime GUI will load the available model for this user. This is the aggregated model of all assigned roles. This means that unauthorized segments of the model will not even be known to the UI. The UI is not laced with unauthorized, hidden elements.
The same counts for the runtime API. When a user accesses the API of the application, the services and endpoints will be initialized for this specific user based on the assigned roles. There will be no service for an unauthorized entity available to the user.
This is our model-driven authorization by design approach, which allows us to leak minimal information about the unauthorized segments of the application. The roles are applied consistently and automatically throughout all tiers of the application. The UI will never be out-of-sync with the back-end or the database.
Note, however, that this mechanism does not absolve the developers and administrators of responsibility regarding security. The runtime components do exactly as the roles and role assignments dictate. A developer may inadvertently make a role too powerful or an administrator may grant the wrong roles to a user.
Protection against abuse
The Thinkwise Platform takes care of many of the technical security considerations when dealing with typical enterprise software. Besides securely handling authentication and applying model-driven access control, the runtime components also protect the applications against abuse.
Typical security vulnerabilities found in the application, presentation and session layer such as injection, cross-site scripting, redirect and forward protection are mitigated automatically by the platform.
Logging and monitoring are available out-of-the-box and can connect to existing monitoring tools such as Application Insights. To read more, click here.
Updates to the runtime components are provided on a short release cycle to be able to react quickly to discovered vulnerabilities in packages and recurring pen tests on the runtime components.
The Thinkwise Platform allows customers to deploy their applications as they prefer. The platform is not exclusive to a certain cloud provider or operating system. You can choose to deploy on-premise on Linux servers, in AWS, Azure or Google cloud using their PaaS services or IaaS services. Or simply install the full Thinkwise Platform on your own Windows desktop.
This freedom allows providers of large enterprise systems to satisfy very specific SLA demands of their customers. On the flip side, this comes with significant ramifications for the security of your environment. The infrastructure is not the responsibility of the Thinkwise Platform as it is not provided as an aPaas environment.
All the security measures regarding authentication and authorization in the higher OSI layers will not help you when the network is not secure. Having a severely outdated webserver or an exposed database server can compromise the application.
Recurring pen tests are recommended to verify the quality of your designed roles and the infrastructure of your choice.
Who watches the watchers?
The Thinkwise Software Factory (SF) and the Intelligent Application Manager(IAM) are the two primary applications used when developing and managing applications built using the Thinkwise Platform. The Software Factory being the IDE, and the Intelligent Application Manager being the application that manages this deployment and authorization.
It is important to note that these two applications are not custom-made products. They are both developed using the Thinkwise Platform! This is extremely powerful and comes with great benefits, for example the fact that all new features are also immediately available in the development environment itself. But in the context of this blog, they are also both subject to the same authentication and authorization mechanisms as the business applications that are built with the platform. This means that you also have an IAM that manages the Software Factory, providing tailor made experiences and authorization levels for all developers and stakeholders involved in the software development. But maybe even more importantly, an IAM that manages an IAM – so you can configure who watches the watchers.
Conclusion: secure and future proof software
All aspects of the Thinkwise Platform have been designed and developed to support applications to run for many decades, to never let them become legacy software.
The built-in flexibility to replace runtime components with new versions and even new technologies allows us to adapt to new security standards that are bound to be introduced over time.
Allowing the developers and administrators freedom for configuring the authentication and authorization, the runtime components take care of most of the technical challenges and security-first principles to bring these configurations to life.
The deployment agnostic approach allows weighing options when it comes to freedom and responsibility for the infrastructure, ranging from your hardware to the use of PaaS services that are automatically kept up-to-date with the latest updates.