Introduction
With the new security layers comes a variety of new security options on different parts of the Ometa Framework. It is now possible to apply security on:
- Objects
- Methods
- Views
- View Functions
- Multi Views
- Context Managers
- Context Manager Functions
- Charts
An extra improvement is the fact that you now can use conditions on your security rules (instead of plain claims) and reuse conditions over multiple parts of the Ometa Framework. You even have the possibility to hide or disable functionality based on the evaluation of the security conditions.
Warning
It is important to note that security is checked at the public API layers:
- Requests to the Generic REST Service (Front-end components like ADM, Context Manager, Custom scripting, ...)
- Requests to the OData Core Service (Method executions via OData, requests made with the Ometa.Framework.Client API, ...)
Which requests are not security checked:
- Method executions in our configuration tool (WpfGUI) because you are already logged on as an administrator.
- Method executions in custom DLL code via the Ometa.CommLib API layers (custom code on server side is trusted).
Configuring and Applying Security
Configuring and applying security in the Ometa Framework goes hand in hand with configuring Condition Sets and using them in the Authorization Policy Control.
More information about how to configure each of them:
Securing Ometa Framework Components
After you know how to configure condition sets and use the Authorization Policy Control, it is time to dig into some examples!
In this chapter we are going to secure a variety of possible components and see what the results are when a user is not authorized.
Keep in mind that for each request made, which targets a securable component, the same functionality is always processed:
Is the user authenticated (Anonymous or not)? | Is the user authorized (Authorization Policy fulfilled)? | Response |
---|---|---|
Yes | Yes | The requested information |
Yes | No | HTTP Error 403 - Forbidden |
No | Yes | The requested information |
No | No | HTTP Error 401 - Unauthorized |
Note
Our own visual components (like ADM, Context Manager, ...) have builtin functionality to process the HTTP error responses and act accordingly (eg: challenge the user for authentication). This way the component also knows when to hide or disable certain functionality or when to show a user friendly message to the user.
If you're planning to make your own requests to our API's, use the table above to handle security related responses.
Securing an Object
When you click on an object, you still have the Security tab. However you'll notice it has been updated to use our new Authorization Policy Control.
We will be using a master data condition set which checks if a user belongs to the AD group Developers.
After this configuration, everything contained in the object inherits this authorization policy.
This means that the following components, which are part of the object, will have the same policy applied:
- Methods
- Views
- Views in views (Single Record, Create, Update, Multi views)
- View functions
- Context Managers
- Context manager functions
- Charts
This is what you'll see when you try to load an ADM when you're not authorized to the object.
Note
Keep in mind that, when unauthorized and the user making the request is not yet authenticated, the ADM will challenge the user to be authenticated and start an authentication flow.
The message above will only be shown to users which are already authenticated but do not fulfill the Authorization Policy (Unauthorized).
Note
It is also possible to configure the ADM to hide itself when the user is unauthorized. This can be achieved by either:
- Setting the Hidden When Unauthorized field on the Ensure ADM building block
- Editing the web part and setting the property Hide When Unauthorized as shown below
Securing a Method
Configuring security on a method works exactly the same as on an object.
Once configured, a user will not be able to execute the method without the proper authorization.
This also includes view -and context manager functions linked to that method.
Important
A user requesting a view linked to that method, will still be able to see the data if he's authorized to that view. If you want to prevent that, configure the same conditions on the view which are applicable on the method.
An unauthorized user trying to execute the method will see this behavior:
Securing a View
Configuring security on a view works exactly the same as on an object.
Once configured, a user will not be able to execute the view without the proper authorization.
After configuration, everything contained in the view inherits the same authorization policy.
This means that the following components, which are part of the view, will have the same policy applied:
- Views in views (Single Record, Create, Update, Multi views)
- View functions
An unauthorized user trying to execute the view will see the same behavior as with an object.
Securing Functionality within a View or Context Manager
The real power of security becomes clear when securing certain functionalities within views or context managers.
Whereas you used to create separate secured pages and views to shield off certain functionality in a view or context manager, you now can stay on the same page and view and use our authorization policies for this purpose.
Let's protect some item and list functions on a view.
Warning
Always make sure that the policies are also configured on the linked views and/or methods itself so there is no way a user can execute them directly when unauthorized.
In the example below we see a multi record view. We will be securing the Delete function and the Reorder Stock functions.
Now we reconfigure the view so:
- The Delete function will be hidden when the user is unauthorized
- The Reorder Stock function will be disabled when the user is unauthorized
And the result when a user is unauthorized. Notice that the Delete function is hidden and the Reorder Stock is disabled.