The Security application discussed in the previous post will enable the following
workflows:
The Security administrator must be able to navigate any roles
and see the members included. Users care about roles. Additionally, the application add and remove of
these members should be enabled from the list and their details should be visible
by double-clicking the items. There need not be grid lines and tab pages to separate
the views. Instead we could use CSS and borderless transitions between views.
These views are the same for each of the member and can include information
such as groups, roles, resources, access levels etc. Mostly, we want the UI to
not be boxy but clear and simple with seamless and smoothed transitions. A
clear white background is preferable to any other colors. So the list of all members in a particular role can be listed on the same page with a white background and no borders for grid. And when the user double-clicks a particular member, the details are shown on the same page. Boxes and borders are great when we comparmentalize the UI parts and great for organizing properties on the UI however the ask here is for simpler information rendering with options to bring details onto the same focus area for the user with minimal peripheral changes. A light stationary hue in the peripheral area actually brightens up the canvas so that the user is drawn towards the simpler format of the information presented somewhere near the center of the page. Technology wise there
can be based on XAML, prism, and .Net stack with little or no other front end
technologies. But the application can be simpler and nicer ableit for security
administration.
Another workflow that we could vision for this application other than adding users to roles as discussed above, is to grant users access to domain objects via both label mapping as well as object hierarchy. Users care about their objects. Note however the premise of the previous discussion was based on row level granularity and not object access. We could exercise object access and object control outside the database while the database has row level granularity. However security applications may have workflows to secure both. But looking at the database schema where each record has row level granularity that is set typically at one time only. ( you may actually want to forbid changing labels of those records because you have evaluated the record for the duration of its existence when roles and all else hasn't changed. Updates to the record does not change the identity of the record and on the other hand changing merely the labels on user input could mean we could end up with an inappropriate label because column constraints may not be able to catch all. This does not mean labels cannot be changed and in fact internal methods may exist to take action on user's behalf) So now let's look at enforcing object access security which is probably the primary workflow of this application. As stated earlier, security admin may want to add security to domain objects and expect it to cascade down to all row level entries. Objects could propagate permissions both on inheritance and composition but the preferred way is inheritance since no traversal is needed. Now coming back to the application to enable object security in a label based schema, the solution is to flatten all the derived objects to the same concrete entities and have them all be labeled the same via updateable views. So in effect we will be updating the row level entries. Note however that the inheritance based flow of security is secondary in priority to directly assigning security to individual objects themselves such as test pass and test results.
Another workflow that we could vision for this application other than adding users to roles as discussed above, is to grant users access to domain objects via both label mapping as well as object hierarchy. Users care about their objects. Note however the premise of the previous discussion was based on row level granularity and not object access. We could exercise object access and object control outside the database while the database has row level granularity. However security applications may have workflows to secure both. But looking at the database schema where each record has row level granularity that is set typically at one time only. ( you may actually want to forbid changing labels of those records because you have evaluated the record for the duration of its existence when roles and all else hasn't changed. Updates to the record does not change the identity of the record and on the other hand changing merely the labels on user input could mean we could end up with an inappropriate label because column constraints may not be able to catch all. This does not mean labels cannot be changed and in fact internal methods may exist to take action on user's behalf) So now let's look at enforcing object access security which is probably the primary workflow of this application. As stated earlier, security admin may want to add security to domain objects and expect it to cascade down to all row level entries. Objects could propagate permissions both on inheritance and composition but the preferred way is inheritance since no traversal is needed. Now coming back to the application to enable object security in a label based schema, the solution is to flatten all the derived objects to the same concrete entities and have them all be labeled the same via updateable views. So in effect we will be updating the row level entries. Note however that the inheritance based flow of security is secondary in priority to directly assigning security to individual objects themselves such as test pass and test results.
No comments:
Post a Comment