Hi Sergio, I've implemented row level access security (effectively making use of the Read Security) in the CMDB and Asset Management, though I did not have to implement Write Security at the time.
Considering the design of AM 6.0, this isn't going to be that clean, but it should be possible... Depending on what your plans for the future are, you could consider upgrading to CMDB 2.0 and AM 7.0 which have a hugely more sophisticated and usable approach to read and write permissions for CI's. But for now, you are correct in that your first step will be to change the permissions of Field ID 1 on each AST form you use as part of the User interface to your Data Model. In AM 6.0 (On CMDB 1.x), the ReadSecurity permission is a dynamic group field, so this can be used to grant read access to CI's. If you set up Field ID 1 with Read Permissions for the "ReadSecurity" group, then only Groups or Users whose Group name or User name exist in this field will see the CI in the AST form when they perform searches. Next, you have to define your own policy and workflow to populate the 'ReadSecurity' attribute for every CI. What you might consider is creating a new "GenericAccess" regular group which can be allocated to all users who normally have Read Access to all CI's...this Group will also then have to be set in the 'ReadSecurity' field for every CI. Everybody else can then be given access based upon other permissions they have (AM 7.0 uses Support Group membership to control Access to CI's for users who do not ordinarily have full access) When it comes to WriteSecurity, this is particularly tricky in AM 6.0 as all fields have been configured OOTB with Write Access for members of APP-Support, APP-Management and APP-Administrator and your users will need to be a member of at least one of these groups to use Asset Management in the first place. This basically means that you're stuck with field permission write access to all attributes for all users that can see CI's. If you really wanted to, you could consider changing the entire permission structure of every attribute, but that's a little drastic and I wouldn't recommend it based upon the effort this will be (this has now at last been implemented properly for us OOTB in CMDB 2.0). If you design your own policy and workflow to populate the 'WriteSecurity' attribute, which is also a dynamic permission field, then you could consider using an Active Link to validate that the current user's login name or at least one of the Groups they belong to exists in the field at the point of modifying a CI on an AST form. If the qualification fails, throw an error message. Alternatively, lock down all fields and buttons on display (again, a nice new feature of AM 7.0). Not a brilliant solution to this in AM 6.0, but I think it should work. The tricky bit is likely to be defining your policy regarding who gets what access and when. HTH Chris > Hello list. > > I am thinking about give more restrictive access to CMDB. Now the > Administrator, Managers and all Support can view and modify all assets in > our CMDB. > The client wants two news groups, one for view all CIs, and other for view > and modify all CIs but he don´t wants all the support people modify all > CIS in the CMDB. > > I have seen that I have to modify all my AST: forms in the "request id" > field in order to delete the public, asignee and submitter permissions and > put the new VIEW group in the request id.... But then I dont understand the > correct use for the CMDB ReadSecurity group if I have to modify all the AST > forms. > > Has anyone implemented permissions in the CMDB?? > Has anyone used the ReadSecurity and WriteSecurity groups?? How you use the > WriteSecurity permission?? > > Any help will been grateful. > Best Regards. > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
