Security

SSO (Single Sign On) #

OAuth 2.0

The app you build in Wizzdi Cloud may allow the deployed app’s users to sign up using their account for other services such as Google or Apple.

Supported OAuth 2.0 providers

• Google
• Apple
• Facebook
• LinkedIn
• Github
• Custom

Set OAuth 2.0 support in the Google Cloud Console

The following section depicts SSO settings for Google accounts. Other SSO providers are not detailed here. More information is available in their respective guides.

Setting up a client on Google OAuth 2.0 when the service is a server (where a secret is required) involves several steps. Here’s a general outline of the process for Google OAuth 2.0 using Google tools.

Note: The following is executed outside Wizzdi Cloud.

For a backend created with Wizzdi Cloud to support Google SSO sign-up, the build backend, that is, the App must register with Google services.

1. Google Cloud Console:
   • Go to the Google Cloud Console.
   • Create a new project or select an existing one.
2. Enable APIs:
   • In your project dashboard, navigate to the “APIs & Services” > “Dashboard” section.
   • Click on “+ ENABLE APIS AND SERVICES” to enable the necessary APIs for your application (e.g., Google Drive API, Google Sheets API, etc.).
3. Create Credentials:
   • Go to the “Credentials” page.
   • Click on “Create credentials” and select “OAuth client ID”.
4. Configure OAuth consent screen:
   • Before creating credentials, you need to configure the OAuth consent screen.
   • Provide the necessary information like the application name, user support email, and developer contact information.
5. Creating OAuth Client ID:
   • Choose the application type (e.g., Web application, Android, iOS, etc.).
   • Set up the name for the OAuth 2.0 client.
   • Specify the authorized JavaScript origins and redirect URIs for web applications.
6. Obtain Client ID and Client Secret:
   • Once the OAuth client is created, you will receive a client ID and client secret. These will be used in the App.
   • These are important and should be kept secure and confidential.

For the specific URLs to set up OAuth clients on other platforms like Facebook, GitHub, Apple, and LinkedIn, you can refer to their respective developer documentation:

• Google: Google Cloud Console
• Facebook: Facebook for Developers
• GitHub: GitHub Developer Settings
• Apple: Apple Developer Program
• LinkedIn: LinkedIn Developer Portal

Setting up an SSO provider in your app

Create SSO provider

Select SSO Provider

Select SSO provider

Select one of the available providers.

You may repeat the process and support multiple providers on your backend.

Fill in the OAuth2.0 fields:

Open the provider for edit:

Fill in the data obtained from the provider management console in the Client ID and Secret fields.

Scopes

In OAuth 2.0, scopes are permissions that define the access level your application has to a user’s data. By specifying scopes, you request authorization to interact with specific types of user information, such as emails or calendars. These scopes are provided as comma-separated values during the authentication process, dictating what data your application can retrieve or actions it can perform on behalf of the user.

Add comma-separated Scope values. In Google OAuth 2.0, these can be any of the scopes here.

For example, if you want to use the user’s email in the App to send emails to the user through SendGrid-consumed API support, you will add email to Google SSO scopes.

For other SSO  providers, use the respective documentation to get the scope list they support.

Use the values obtained from the Auth 2.0 provider for Client ID and Client Secret, and add comma-separated scopes to the Scopes field.

SSO In Deployment #

SSO providers’ usage at deployment.

Regardless of where the App is deployed, the client-side user interface should provide the required access buttons for each OAuth 2.0 provider.When building the client user interface without using Wizzdi Cloud User Interface builder, The URL associated with such a button should be constructed as follows:

https://[server URL] oauth2/authorization/[provider name].

where the provider names are Google, Apple, GitHub, LinkedIn, or Facebook. A single one should be selected.

If the App was deployed on Wizdi Customer’s cloud, the URL for Google will be:
https://[app-name].[workspace-name].cluster.wizzdi.com/oauth2/authorization/google

When deploying on Wizzdi Cloud customers’ cloud, you can copy the Swagger URL from the App overview if it was deployed and replace the suffix as follows:

Replace swagger-ui.html with  oauth2/authorization/google 

Once this URL is activated, the process is pretty automatic; if this is the first time this provider is used, the user is prompted to approve access to Wizzdi Cloud, and subsequent accesses are transparent.

Note that switching among providers, for example, between Google and Apple, is equivalent to having two different users. Likewise, Do not use any of your emails for standard email password sign-up if this email is associated with any SSO provider.

Permissions #

Wizzdi Cloud supports defining role configurations inside permission configurations on all three current runtimes (Spring, Flexicore, Flexiocore Boot). This provides Role-based access control to API endpoints.

In addition, the FlexiCore and Flexicore Boot runtimes have a robust security framework emphasizing multi-tenancy and role-based access control (RBAC) for API endpoints and data objects. This security framework is crucial for applications that require stringent data isolation and access control mechanisms, especially in environments serving multiple user groups or tenants. Here’s an expanded view of how this is implemented and managed:

Tenant and Role-Based Access Control

• Tenant Support: Multi-tenancy is a software architecture principle in which a single instance of the software serves multiple customers or tenants. FlexiCore achieves this through predefined database objects that segregate data by the tenant. This ensures that data is isolated between tenants and that access controls can be enforced at the tenant level.
• Role-Based Access Control (RBAC): RBAC is a method of restricting system access to authorized users. In FlexiCore, roles are defined to define permissions or access rights. These roles are then assigned to users within a tenant, determining what actions they can perform and what data they can access within the system.

Predefined Database Objects

• At the initialization of a backend built by Wizzdi Cloud and using any of the two FlexiCore runtimes, a set of predefined database objects related to security (like roles, permissions, and tenant information) are optionally created if so defined in Wizzdi Cloud while developing the App. These objects serve as the foundational elements of the security model, ensuring that the application starts with a basic level of access control and data isolation. For Spring runtime, defined roles and access to API endpoints affect the generated code.

API Endpoints for Security Management:

• FlexiCore provides multiple API endpoints dedicated to managing these security-related database objects. Administrators can dynamically modify and expand the roles, permissions, and tenant configurations when the app is deployed through these endpoints as the application evolves. This allows for a flexible and responsive security model that can adapt to new requirements or changes in the operational environment.

Web-Based User Interface for Security Objects.

• When deploying a FelxiCore-based backend, an optional user interface can be added, providing an easy-to-use security objects management console. This user interface makes use of the security-related API endpoints.

Adding and managing permissions

Accessing permissions

The Wizzdi Cloud user interface’s Permissions menu option is the entry point for configuring and managing these foundational security objects.

The Permission Configuration fields.

Permission Configuration #

In the context of Wizzdi Cloud, permission configuration is a critical aspect that dictates access to various components, such as API endpoints and data. This configuration process differs between Spring and FlexiCore runtimes.

In Spring Boot runtime:

• Permission Configurations are more integrated with the codebase itself. The configurations directly influence the code that is created and executed.
• There is no API at runtime to manage Roles and permissions.
• This implies that changes in permission configurations necessitate modifications in Wizzdi Cloud, committing and deploying the App again.

In FlexiCore, both runtimes:

• Permission configurations define access at two levels: operations (API endpoints) and data.
• Once the server starts running, any missing configured permissions are instantiated within the database, making them active and enforceable.
• FlexiCore also provides  API endpoints specifically for managing these permissions. This API allows permissions to be created, modified, or deleted, allowing for dynamic control over access to data and operations.

 Permission Configuration  options

• Tenant Configurations (Flexicore runtimes Only) create predefined and missing Tenants when the App is deployed.
• Role Configurations create predefined and missing Roles when the App is deployed.
  Roles are always defined per tenant and present in the database.
  With Spring Boot runtime, as there is no multi-tenancy support, roles are app-wide and present in the generated code, not in the database.
• Permissions on API endpoints: Access control for each endpoint is delineated by the tenant or role specifications, encompassing three primary modes: Execute Without Security, Anonymous Execution, and Secured Access. The latter, serving as the default mode, permits all authenticated users endpoint access, barring the existence of explicit Permission Configuration.
  Within a Spring framework, such configurations may specify one or multiple roles authorized for endpoint access, denying access to users not associated with these roles.
  In Flexicore runtimes, access control mechanisms are augmented by providing default Tenant behavior and dynamic management through a security API at runtime. This default Tenant behavior introduces tenant-specific access control policies, which are subject to being overridden by role-based permissions.
  In Flexicore run times, as with all other permissions configurations, API access is stored in the database and can be modified on a deployed App through the provided APIs or permission management app.

You may define multiple Permission Configurations. The final behavior at runtime is a combination of all configurations. In most cases, a single configuration is sufficient.

Once the permission configuration is created, the following view is available.

Tenant Configurations (Flexicore Runtimes only)

To create and manage Tenant Configurations, click on Tenants.

The above dialog also appears when managing the existing Permission Configuration.

Create Tenant configuration.

To create a Tenant Configuration, add a name. The tenant is created when the App runs on the server.

Europe Tenant

The view of Tenant Configurations is similar to this one:

Role Configurations (all runtimes)

When using Flexicore runtimes, roles and permissions are configured per tenant, allowing tenant administrators to define roles.

Role Configurations are created within Tenant Configurations. This setup defines the permissions and access levels assignable to users within a tenant’s domain on Wizzdi Cloud.

When FlexiCore runtimes are utilized, role management extends to the server level through API endpoints. This enables the creation or adjustment of roles directly on the application’s target server. The roles available at any given time are predefined through Role Configurations within the Tenant Configurations and those created or modified using the API endpoints. This design allows for managing roles based on immediate needs or changes.

When running a Spring runtime, Tenants are unsupported, and Roles are App-wide.

Create a Role Configuration

Role Configurations, empty view.

Filled Role Configuration.

Access Rules priority

In systems where permission configurations might conflict, the hierarchy prioritizes permissions assigned to a Role over those set at the Tenant level, allowing role-specific permissions to override tenant-wide defaults.

FlexiCore-runtime-based applications utilize Security API endpoints that allow for precise permission control at the AppUser level. This means permissions or denials assigned to an individual user will override those assigned to the Roles and Tenants with which this user is associated.

This hierarchical approach to permission control ensures that when conflicts arise, the system resolves them by prioritizing user-specific permissions over role-based permissions and role-based permissions over tenant-wide settings.

FlexiCore-based runtimes using the standard API are the only runtimes that can have AppUsers permissions applied at runtime.

Operation Permissions Configuration.

This section applies to pure Spring runtime, Flexicore runtime, and Flexicore Boot runtime.

Create a Permission Configuration for API endpoints (operations).

When creating a permission configuration, we define two components. The permission target includes a list of tenants and roles associated with one or more operations.

When a tenant is associated with permission, it defines the default behavior for the included operations for that tenant on a running system.  Tenant administrators may want different system behavior for their users. Some may wish a loose system, while others prefer restricted access by default. When the access is limited at the tenant level, associating with roles is required to open it for some of the tenants‘ users.

It should be noted that this flexibility of changes on a running system is available only with Flexicore runtimes. Changing the permissions on a pure Spring runtime requires changing the App in Wizzdi Cloud and redeploying the App.

In the above image, the targets selected are one Role from a Tenant and one Tenant, the America Tenant.

The permission pertains to all users of the Europe Tenant (marked in blue) and only to the Administrator Role (marked in yellow) in the America Tenant.

In the above image, two endpoints have been selected when selecting an endpoint. Either allow or deny may be chosen.

Security On Exposed APIs #

Available in all runtimes.

The exposed API endpoints have additional settings defining their behavior and the permissions related to them.

Accessing the security settings on an Exposed API endpoint.

When setting security directly on the Endpoint, The following options are available:

• Execute without Security: At runtime, the user must be signed in to access the endpoint, and no other security restrictions are applied.
• Anonymous Execution: Anyone can execute this endpoint at runtime. For example, a sign-in/sign-up endpoint must be accessible to all.
• Restricted execution: when none of the above two options is selected, the following section applies.

Select Security Options on an API endpoint.

When configuring the access to an endpoint, we first need to select Tenants or Roles. 

Then click on the ‘+’ sign to add a Tenant Permission Configuration or a Roles Permission Configuration.

When Adding a Role/Tenant Configuration, you can select an existing Permission configuration or create a new one.

Selecting a Tenant Configuration for the endpoint.

Adding a Role Permission Configuration or Tenant Permission Configuration may be repeated. A summary of all such configurations created so far is available.

Permissions on Data #

Important Note:

Support for data access control in Wizddi Cloud is available for FlexiCore and FlexiCore Boot runtimes only. Furthermore, all entities must directly or indirectly extend the Flexicore-defined entity SecuredBasic.

As in this domain model, Book and Author both extend the SecuredBasic entity.

Entities extend SecuredBasic.

Model-Level Permissions

• Design Phase on Wizzdi Cloud: Model-level permissions can be established during the application’s design phase. These permissions define access controls for entities within the application’s model, setting broad access rights for Roles or Tenants to all records of a particular entity.
• Runtime: Model-level permissions can be modified and created at runtime using the provided API.

Instance-Level Permissions

• Runtime only: Instance-level permissions are specific to the runtime environment and are applied to individual data records within the application. These permissions allow for granular control over access to particular data instances.
• Instances Groups: The run time instance-level access control includes the concept of Instance Group, where a heterogenous collection of instances can be subject to permissions as a whole.
• Supported by API endpoints: Instance-level permission management is available only at runtime using the provided API endpoints and only for Flexicore and Flexicore Boot.

Model-level permissions, the details.

Data permissions, no permissions yet.

Click on Create Data Permissions.

In the above dialog, you must set the Target, a list of Roles and/or Tenants, the Subject, the entities for this permission, and the operation. The API endpoint you want to associate the permission with.

Multiple targets, Entities, and Operations can be included in a single Data Permission Configuration.

In the above screenshot, targets, Tenants, and Roles are marked yellow, Entities from the data model are marked blue, and operations and API endpoints are marked green.

When Add Permissions is clicked, a list of permissions generated from the above is displayed.

Applying Data Model Security From Domain Model Editor.

Note: When an app is developed using Wizzdi Cloud, the structure and properties of its entities (such as data models or object types) are predefined. However, the actual data instances (or records) corresponding to these entities are generated only when the app is deployed and used in a live environment. Consequently, security measures related to the entities can be implemented during the app’s design phase within Wizzdi Cloud.

In addition to these design-time security configurations, Flexicore runtimes also support applying dynamic access control measures at runtime through its system APIs. These APIs can be used to apply both Entity-level and instance-level access rules.

When an Entity is selected in a domain model diagram, and the runtime is one of Flexicore’s runtimes, the ‘Manage Security‘ button is available.

Manage the Security of an Entity.

When managing an Entity’s security, Derived Security or direct Security settings can be selected. In derived security, the Entity’s security becomes the same as that of a related Entity; see below.

Entity Security Settings (direct)

The Entity Security setting is defined for this Entity, for example, if a Role can operate on all Entity instances. Finer-grained access control on specific instances or a group of instances (Permission Groups) is available only at runtime.

To add an Entity Security permission, click the ‘+’ sign after you select Tenants or Roles.

When ‘Tenants‘ is selected, the entity permission created defines the default behavior in this tenant.

Data-model permissions

You have the option to create a new Permission Configuration or to use an existing one.

Define the default Tenant-wide permission on an Entity.

Derived Security #

Derived security means that the access permissions assigned to a particular entity automatically affect the access permissions of other entities linked to it through a derived security relationship. This relationship is defined based on the data model’s structure, where entities are associated through a one-to-many relationship.

How Derived Security Works

• Defining Access Rights on a Primary Entity: When access rights are granted or denied to an entity (the primary entity), these permissions are considered when determining access to other entities associated with the primary entity in the context of derived security.
• Associated Entities’ Access Rights: Entities with the primary entity associated with derived security inherit the access rights from that primary entity. If an entity is configured to derive its security from another entity, any access rights defined for the primary entity will similarly affect the derived entity. Data model security can be configured on Wizzdi Cloud and managed through the provided APIs.
• Influence on Associated instances: Entity instances of an Entity defined with a derived security get access rights from the associated instances of the Primary Entity defined in the derived security. Instance-level access control can only be managed through the provided API endpoints in runtime. A web app for managing access rights is available.

Example Scenario: Entity Association

Consider a scenario with three entities: Project, Task, and User. If the Task entity is associated with the Project entity in such a way that its access rights are derived from the Project, and a user has restricted access to a specific Project, then by the principle of derived security, the user will also have restricted access to the Tasks associated with that Project. Similarly, if a User entity’s access to projects is defined through derived security, the user’s permissions on the Project entity would affect their access to related entities.

Configuration and Implementation

• Data-Model Configuration: In the data model, entities must be explicitly configured to utilize derived security, specifying which fields or relationships govern the derived permissions. This setup involves identifying the paths through which security settings are inherited.
• Runtime Behavior: At runtime, the application evaluates the derived security configurations to dynamically apply the appropriate access permissions across entities based on the established relationships and inherited rights. This evaluation ensures that the access control logic remains consistent with the data model’s structure and the intended security policies.

Registration #

Users registering to your backend may be associated with a default Role. To set the default role, select one of the predefined Role Configurations.

Admin User #

Define the user having full rights on permissions in the system. When using Spring runtime, this user can access all the exposed endpoints.

Permissions Web App #

In Flexicore Runtime, in addition to having open access to all exposed endpoints, this user can manage permissions, tenants, roles, and users via the available web app.

Below are some screenshots of the Web App. Solution providers can use the Web App or create a user interface based on the exposed API.

Tenants management.

Roles management.

Users management. Tenant and Role associations are displayed.

Permissions management for both operations and data.

An instance-group management.

The above screenshot depicts a single instance-group management. An instance group groups multiple instances so that permissions to the entire group can be easily managed.

Not shown here is the Operation-Group management, which allows concise permission management on multiple operations.

The above screenshots are not full and are presented here just to help you understand the permissions management web app.