Chris,
Thank you a lot for this great response... It´s just that I believed.
Yes I forget say that my CMDB is 1.0 patch 2 and my AM is 6.
Congratulations for implement the row level security in the CMDB, I will go to do the same thin in order to grant view permissions.
But for establish write permissions I think in a filter in asset base, not is the cleanest way but is the fastest.
Thank you very much.
Best Regards
2006/7/17, Chris Williams <[EMAIL PROTECTED]>:
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
__20060125_______________________This posting was submitted with HTML in it___
