The ADF framework uses a very efficient and flexible security mechanism. Custom security attributes can be added to the following elements:
- business classes
- properties on business classes
- use-case controllers
- public methods on use-case controllers
Security details are are stored in the database. A standard framework use-case makes it possible to add an ACL (Access Control List) to each security object. The standard .NET security mechanism only makes it possible to permit or prohibit actions (methods). The ADF security mechanism is much more flexible. The ACL lists determine four different security levels: invisible, empty, read-only, full-access. We can also determine a default security level for each ACL list. The default will be used when the user is not found in any user-group in the ACL list. In general this makes very compact ACL lists possible.
The database itself is secured via one single login. No security details are added to the database tables. In the GUI the custom ADF controls automatically "read" and respond appropriately to the available security information in the Carrier objects passed from the AL.
Thus, GUI controls will automatically become invisible or read-only. Actions not permitted will be blocked automatically by invisible or disabled command buttons or menu items etc.
A complicating factor in this area is the fact that the invisible/read-only/enabled state of GUI controls is not always determined exclusively by the security settings of the application. The runtime state of a use-case can also influences these settings. For example, when editing an object, the New or Delete command buttons must be disabled (or invisible). Only the Save and Cancel buttons will be enabled.
To make things even more complicated, in some scenario's dynamic security can be necessary. Dynamic security settings depend not only on the identity of the user, but also on some runtime data. For example a certain user might be permitted to edit a price of a product only if it is of a certain product type or price type. Applications with this type of dynamic security tend to have very complicated and difficult to maintain GUI code.
Because the ADF framework uses a standard security mechanism based on centralized security metadata the developer does not have to write a single line of security code in the GUI. A standard mechanism in the AL creates the Carrier objects that will be sent to the GUI. These DataCarrier objects contain all necessary security settings based on an evaluation of the static security settings, runtime state of the use-case and dynamic security rules if necessary.
Static security rules are implemented in the form of the mentioned ACL lists in the database.
Security rules based on the runtime status of the use-case and dynamic security are implemented in custom security objects per use-case. These custom security objects use a standard interface and integrate seamlessly with the static security rules of the ACL lists.
This centralized and standardized security mechanism makes it very easy and flexible to implement and change security at any moment in the application life-cycle. As a result it is no problem to implement the whole application without adding any security details. This makes rapid initial development possible, concentrating on the functional essentials. In a later stage all security details can easily be added without any rework.
For complex applications this flexible security mechanism might turn out to be the most important and time-saving single asset of the ADF framework.