Granular user/group authentication and resources

[Andy Ashley]

Hello,

I would like to know if it is currently possible to do the following:

For e.g -
I have a Nagios system that monitors all of our customer servers and 
each customers' hosts are grouped by company name.
Any alerts generated are sent to that host group's associated contact 
group which has that company's staff as contacts.
What would be really useful, is if a customer could log in and only view 
and make changes to those hosts that are in their host group, i.e lock 
that customer down to
the hosts and services that concern them, isolating them from rest of 
the monitored hosts and customers in the interface.
As it stands now, any customer could log in and view any other 
customers' hosts and possibly make changes depending on permissions 
granted to that user.
Obviously not an ideal situation and something preventing us from 
granting customer access to Nagios.

I have read through the auth sections of the docs but as far as I can 
tell it only seems possible to limit use of certain commands and set 
privledge levels by user/group. Perhaps I misssed something..
Is this something that can be configured with a present version of 
Nagios or if not, will this be possible in future releases?
This would be really handy for us as customers could essentially log in 
and deal with their own alerts instead of requesting our support team to 
disable an alert and re-enable when the issue is resolved.

Any input would be much appreciated..

Thanks.

Andy.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null