Skip to main content

Module and Feature Requirements

RM1 Security

Requirement
Incorporate a security mechanism to authenticate and authorize users in the system.
Background
Applications developed on the platform should be secure, providing adequate protection for both users and for hosted services.
Solution
The ELEFLEX® platform utilizes Microsoft ASP .NET Identity and OWIN as the default security mechanism. This is integrated into the service command execution pipeline that allows authenticating and authorizing during the request lifetime.

RM1F1 Users, Roles and Permissions

Requirement
The security mechanism must allow for user, role and permission entities.
Background
Existing applications that will be upgrade to the ELEFLEX® platform currently use a notion of users, roles, and permissions. In some cases, a large effort was made to create security matrixes that allow an application to fully secure itself.
Solution
The ASP.NET Identity security mechanism has dropped support for permissions and created a new entity for claims. We have expanded the identity model to additionally keep track of permissions, adding them along with roles in the new model. This allows transparent use with current security checking attributes that use roles, but can also be expanded with custom objects.

RM1F2 Effective Date Enforcement

Requirement
The security mechanism must allow for effective dates to determine when a user assigned role or permission is available.
Background
Existing applications that will be upgrade to the ELEFLEX® platform currently use this notion of effective dates on assignments.
Solution
The ASP.NET Identity security mechanism does not have support for effective date assignments. The platform has changed the underlying identity persistence stores to additionally keep track of effective dates and only return those items that are currently valid.

RM1F3 Dependent Role Hierarchy

Requirement
The security mechanism must allow for roles to be assigned to other roles, so that when one role is assigned to a user, any child roles of that role are automatically applied.
Background
Existing applications that will be upgrade to the ELEFLEX® platform currently use this notion of applying dependent roles based on an assigned role.
Solution
The ASP.NET Identity security mechanism does not have support for parent/child dependencies. The platform has changed the underlying identity persistence stores to additionally keep track of dependencies and return child roles of the user’s assigned roles.

RM2 Logging

Requirement
Incorporate a logging mechanism into the design to store errors, audits and warning messages.
Background
Logging provides application health and monitoring. Storing this information provides developers the ability to help discover application defects, execution and processing debugging, warnings and other related information.
Solution
The platform exposes a logging service to store application messages during the execution of the application. A service contract is provided that allows sending and exposing message information while providing a centralized storage mechanism for all system services.
Developers access application logging my accessing the Eleflex.Logger object. Calling the Current property allows execution of error, debug, warning, info, and fatal methods with standard overloads.

RM2F1 Required Data

Requirement
The logging mechanism must allow storage of data:


Background
Including the data mentioned above will provide greater monitoring and debugging of application health within the infrastructure.
Solution
The logging mechanism includes these data fields on the LogMessage object and messages can be sent to the application log using the Eleflex.Logger object.

RM3 Versioning

Requirement
Incorporate a versioning mechanism into the design to allow modules to self-upgrade after upgrading their NuGet package.
Background
Modules will often require data persistence, usually with a database engine. Often the schema or data may change between released versions of software. This versioning module will provide a path so the module can upgrade itself.
Solution
The platform exposes a versioning service to store an installed module’s version information. On application startup, the system will dynamically load all the module’s upgrade patches, determine the execution tree for patches and execute each in order.