Security application
In our previous posts we talked about a security administration application that enables domain object based security. We discussed several scenarios, features, approaches, and in general discussed a UI application that would enable configuration of user and object security. Today we try to improve upon the notion of user role management and it's place in this security application. Typically many of the web applications will leave user management to administrators and tools outside the application such as the operating system applets. And integrating user management with that of system, there is a lot more features and tools available for user management. Then there are applications like SiteMinder as well for single sign-on feature. And there are some interoperability tools that lets you configure users across platforms. Even that is being pushed to system level such as with Active Directory integration freeing up the application to do more for its business users.
Therefore unless there is a business need for security, the applications don't support these kinds of operations. There might be other reasons to require security such as when web applications do have different membership providers that keep user information in different stores such as asp.net stores, SQL stores, local file systems based store that require a common interface for management. Moreover, there may be mobile users who may require access that needs to be secured. In such cases, the mobile applications may not be hitting the web application UI but the API interfaces. Those methods may also need to be secured for different users and applications.
Overall, there's reasons for mapping users with objects and methods.
Most times these mapping is dynamic like a decision tree or a classifier that dynamically groups users and maps them to resources. This can be a policy server where the different policies or classification rules can be registered and maintained. The policies define which groups are associated with which pool of resources. The code to associate users with groups can be a scalar user defined function that takes incoming users and groups them. These groups have no meaning inside of the system other than a scalar value. The resources are what the application knows. They can be classified into some organizational units called pools. The users are temporary and they can change often. We keep track of more stable groups and associate users with groups. The groups can have certain privilege levels and are different from roles in that the roles are a subset of the groups but groups are what pools of resources assigned to. By having a dynamic classification mechanism, the users can be switched to one or more groups.
Policy server and access control for a user is a complex topic involving many different organizational units. Take IPSEC for network access control. There are many parameters for controlling IP security.
In our previous posts we talked about a security administration application that enables domain object based security. We discussed several scenarios, features, approaches, and in general discussed a UI application that would enable configuration of user and object security. Today we try to improve upon the notion of user role management and it's place in this security application. Typically many of the web applications will leave user management to administrators and tools outside the application such as the operating system applets. And integrating user management with that of system, there is a lot more features and tools available for user management. Then there are applications like SiteMinder as well for single sign-on feature. And there are some interoperability tools that lets you configure users across platforms. Even that is being pushed to system level such as with Active Directory integration freeing up the application to do more for its business users.
Therefore unless there is a business need for security, the applications don't support these kinds of operations. There might be other reasons to require security such as when web applications do have different membership providers that keep user information in different stores such as asp.net stores, SQL stores, local file systems based store that require a common interface for management. Moreover, there may be mobile users who may require access that needs to be secured. In such cases, the mobile applications may not be hitting the web application UI but the API interfaces. Those methods may also need to be secured for different users and applications.
Overall, there's reasons for mapping users with objects and methods.
Most times these mapping is dynamic like a decision tree or a classifier that dynamically groups users and maps them to resources. This can be a policy server where the different policies or classification rules can be registered and maintained. The policies define which groups are associated with which pool of resources. The code to associate users with groups can be a scalar user defined function that takes incoming users and groups them. These groups have no meaning inside of the system other than a scalar value. The resources are what the application knows. They can be classified into some organizational units called pools. The users are temporary and they can change often. We keep track of more stable groups and associate users with groups. The groups can have certain privilege levels and are different from roles in that the roles are a subset of the groups but groups are what pools of resources assigned to. By having a dynamic classification mechanism, the users can be switched to one or more groups.
Policy server and access control for a user is a complex topic involving many different organizational units. Take IPSEC for network access control. There are many parameters for controlling IP security.
No comments:
Post a Comment