Having worked on an insurance administration application in Baltimore, I can recognize several feature requests from a security provisioning application. What sets the insurance administration application aside is that there are several roles for the administrators and legality around the HIPAA rights for information confidentiality. Moreover, the administration tasks require many workflows to be explicitly restricted based on roles and rights. As an example, a plan maintenance requires checks against specific dates of administrator activity based on which controls and consequently workflows are disabled. When the UI talks to a middle tier WCF service and data stores behind it, these checks are plumbed all the way through the service and to the datastore.
In the application that I worked on, we even decided to keep a separate database which we referred to as security db. This database was for primarily for defining RBAC access but we were interested in several other things as well. For example, we had a catalog of user controls that were to be enabled or disabled and visible or invisible based on the user context. The user roles were also differentiated based on whether they were for internal or external users. Vitually every sections of administration required checks and safeguards between users and their usages so that the plans were safe and safeguarded from being invalid.
Let's look at a few of these features now.
First the roles have to be differentiated. Typically they are broken down into increasing levels of privilege but some of the roles can be split into the sections of the workflows as well especially if they do not interact with each other. Roles such as plan data entry, plan administrator, group administrator, account administrator are derived from scopes of influence or segregated on the workflows or business usages. Roles can also be differentiated between Intranet and Internet as well as geography based.
Second the grant and revoke of access to different roles should be made easy. Revoking should be automatic and can be determined from the specific expiration time associated with the grant. Access could be granted to different business objects and tied to their lifetimes or renewed periodically.
Third the application should integrate with active directory so that the application need not maintain the user accounts and their memberships can be offloaded outside the application. User accounts using https and http are based may require membership providers but these are also mapped to roles.
Fourth, the application should have a UI that makes it easy to associate users with resources, their access levels and their privileges. A simple grid may not be sufficient since the security administrator may find it onerous to tick each and every privilege to be granted. At the same time, hierarchy and automatic cascading of privileges via composition and inheritance of objects may come in handy.
Fifth, the application should have a default audit trail so that grant and revokes are easily available together with the page where they are facilitated. Items requiring attention based on audits should be flagged to the security administrator so that appropriate actions can be taken. Usability is a key criteria for security applications and governance just as much as they are for any others.
In fact, security administrators should have a dashboard that should capture and show all items pertaining to security management and this should be the landing page for the administrator.
Sixth, the application should consider that users can wear multiple hats and be a member of different groups at the same time. They can also change from one to another sequentially over time. Such access cannot merely be state based. There needs to be validation associated with adding and removing from each group.
Lastly, the application should tightly control its data. It would not be inappropriate to encrypt a security database.
In the application that I worked on, we even decided to keep a separate database which we referred to as security db. This database was for primarily for defining RBAC access but we were interested in several other things as well. For example, we had a catalog of user controls that were to be enabled or disabled and visible or invisible based on the user context. The user roles were also differentiated based on whether they were for internal or external users. Vitually every sections of administration required checks and safeguards between users and their usages so that the plans were safe and safeguarded from being invalid.
Let's look at a few of these features now.
First the roles have to be differentiated. Typically they are broken down into increasing levels of privilege but some of the roles can be split into the sections of the workflows as well especially if they do not interact with each other. Roles such as plan data entry, plan administrator, group administrator, account administrator are derived from scopes of influence or segregated on the workflows or business usages. Roles can also be differentiated between Intranet and Internet as well as geography based.
Second the grant and revoke of access to different roles should be made easy. Revoking should be automatic and can be determined from the specific expiration time associated with the grant. Access could be granted to different business objects and tied to their lifetimes or renewed periodically.
Third the application should integrate with active directory so that the application need not maintain the user accounts and their memberships can be offloaded outside the application. User accounts using https and http are based may require membership providers but these are also mapped to roles.
Fourth, the application should have a UI that makes it easy to associate users with resources, their access levels and their privileges. A simple grid may not be sufficient since the security administrator may find it onerous to tick each and every privilege to be granted. At the same time, hierarchy and automatic cascading of privileges via composition and inheritance of objects may come in handy.
Fifth, the application should have a default audit trail so that grant and revokes are easily available together with the page where they are facilitated. Items requiring attention based on audits should be flagged to the security administrator so that appropriate actions can be taken. Usability is a key criteria for security applications and governance just as much as they are for any others.
In fact, security administrators should have a dashboard that should capture and show all items pertaining to security management and this should be the landing page for the administrator.
Sixth, the application should consider that users can wear multiple hats and be a member of different groups at the same time. They can also change from one to another sequentially over time. Such access cannot merely be state based. There needs to be validation associated with adding and removing from each group.
Lastly, the application should tightly control its data. It would not be inappropriate to encrypt a security database.
No comments:
Post a Comment