Re: Row level access with flashboards
Thanks Carey and David. I really appreciate the feedback. Carey, I didn't think about it from a statistical information point of view. With the way it currently works an admin/developer has the option to show statistical information but still protect the actual record as you mentioned. If it were locked down to row level permissions this would not be an option, limiting design capabilities. The desired locked down result could be obtained by using the user's group list in the FB Variable qualification. David, thanks for confirming this is as designed (again your participation in this list is greatly appreciated). Your explanation of how it technically works helps. I do have a little trouble with understanding how defining the permission at design time (mentioned by both yourself and Carey) relate to the permission of the record data being displayed. The permissions defined in the admin tool grant right to see the flashboard object(s) but does not have any effect on record data being displayed in the FB, correct? This may be taken a bit out of context for flashboards and row level access but in BMC Remedy Action Request System 7.0 Concepts on page 101 there is the following section: The additive nature of permissions Access control in AR System is additive. Each user starts out with no access permissions; administrators then add permissions as needed. In this way, AR System implements strict access control. Administrators must make a conscious decision to grant access to specific groups on a case-by-case basis. I usually take the start with no access and grant it as needed approach. That may be why I was caught a bit off guard when I noticed this behavior. To look at the other side of the UNIX disk usage example... Now a list of valid user accounts has been created (possibly ordered by most active ones) that could be use to try an launch an attack on a system. Granted the list could show full name and not the actual username... I get your point, just a little bit of devil's advocate ;-) Jason -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Easter, David Sent: Tuesday, September 11, 2007 9:19 AM To: arslist@ARSLIST.ORG Subject: Re: Row level access with flashboards It is as designed and not considered a defect. The thing to keep in mind is that the admin user is typically the one doing the query [to be able to see information across multiple permission groups] for the flashboard (as defined at design time), not the user. Thus, since the admin can see all data, all the info is passed into the high level response that Flashboards use for display. As mentioned, the data itself is not available and is protected by row level security when users drill down. It's kind of like if you wrote a program (as root) that listed the users on a UNIX system with the highest disk usage for everyone to see - you would be posting high level information about each user (e.g. disk usage), but the users themselves could not see the actual data that was taking up the space. -David J. Easter Sr. Product Manager, Service Management Business Unit BMC Software, Inc. The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black Sent: Tuesday, September 11, 2007 6:12 AM To: arslist@ARSLIST.ORG Subject: Re: Row level access with flashboards Jason, I think that what you are seeing is as designed. I hold this position because you can control the permissions (at design time) to the Flashboard object. So the developer has to have some ability to expose or hide the data for the targeted users. I think the real difficulty is that statistical information (like Count, Max, Min, etc) might need to be done across all of the application level restrictions for management to really get the whole picture for the business. So I can see a good argument for allowing Flashboards to show such things. However, when the user goes to drill down into the data, then I would think it reasonable for the results to be limited to the portion that the individual user has access too. Example: Flashboard to show number of order that are 4 or more days old that are not yet Sent to the customer. I would think that the President would have enough access to see all order from all departments. So when they drill down they see the whole picture. However a head of a department might only see the orders from their department when they drill down. I would also suspect that the Group By clauses would likely match (very
Re: Row level access with flashboards
Jason, RE: The permissions defined in the admin tool grant right to see the Flashboard object(s) but does not have any effect on record data being displayed in the FB, correct? Since you are more interested in the technical details... here is a quick overview of what I see going on with Flashboards. Actually, the data that Flashboards displays is a separate data set than the source data that the Flashboard variables point at. FB:History and FB:History Summary if memory serves is the actual data stores used by the Flashboard objects. It looks like the v7.1 version of these forms the data is totally locked down and only an Admin can actually see the cached data. (The form and the rows are Public [which seems silly to me], but the actual values are admin only.) The data is collected by the Flashboard server based on the definition of the Flashboard variables as an admin user. So when the users are looking at a Flashboard they are really seeing the FB:History and FB:History Summary data and not the source forms that the variables are pointed at. However, when they drill down then the user is directed to the Source form with the proper qualification to match the Variable/group by/additional Flashboard qualification/restrictions for the UI that the user is clicking on. That is then also restricted to the users Group List access for the source data. HTH. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap Pick two. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Row level access with flashboards
Thank you both for the responses. It is good to know that I am not
completely crazy. Robert, you may be on to something with the Mid-Tier user,
especially if there isn't any SQL that limit the results to a real user's
group list. I didn't get a chance today to work on it but post my results
once I do. I have a coworker with a custom 6.3 p21 system and he mentioned
that he has a flashboard that appears to be respecting the row level access
but we are going to verify.
Here is some more detail regarding the scenario:
We will have multiple contractors who are responsible for different sites
using our system. They should not be able to see each other's areas of
responsibility (they should not be able to use the data in the system to
their bidding advantage against competitors, volume of tickets, time to
resolve, etc).
To support this there are two dynamic groups AC_WriteAccess 60001 and
AC_ReadAccess 60002 and corresponding fields on the HPD:HelpDesk and
SHR:ConsolidatedList forms. These groups have permissions to field '1' on
both HPD:HelpDesk and SHR:ConsolidatedList (as well as Assignee, Submitter
and some supervisory groups who see all tickets (yes I checked that my test
user does not meet any of that criteria)).
We are only actively using AC_WriteAccess but AC_ReadAccess is there (a
similar setup as CMDB/AM. I have a filter on the Help Desk that sets
'AC_WriteAccess' = $Assigned To Group+$ when the value of 'Assigned To
Group+' 24006 changes. I added to AC_WriteAccess to the 2 filters that
push to SHR:ConsolidatedList (one on Submit and one on Modify).
This all works well in the 'Support Requests' 26000 table on the
Remedy Support form without any modifications. My expectation would be
that the flashboards on the Remedy Support form would also only reflect the
requests that the user has permissions to without any modifications. I
realize that I could update the FB's to query the user's group list but my
current mission is to see if I am seeing the as designed behavior or is this
a bug. This may be a good gotcha to know about when designing flashboards.
Thanks again,
Jason
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Robert Molenda
Sent: Monday, September 10, 2007 2:41 PM
To: arslist@ARSLIST.ORG
Subject: Re: Row level access with flashboards
**
Interesting question!!
I'm on 7.0.1 Patch 1, and did some testing with the HPD:Incident Management
Console (and the management view within), and taking API+SQL Traces, the
queries executed as defined by FB Variables, without any extra sql
attached, (Field 1, 3, 112, 6. restrictions)..
It also executes as the user context 'Mid-tier', which is the internal
account, so it might be thought of as an Administrator level account.
I was hoping to find an Impersonate User entry in the API Log, but alas,
none was found. (hum, that IS logged right??)
I DID see where Mid-Tier was getting the user's group list, etc but nothing
was in the SQL Query.
I will (as Joe is going to do as well), perform some additional testing,
because that is an interesting conundrum of data-access.
Thanks-n-advance;
HDT Platform Incident / Problem Manager Architect
Robert Molenda
IT OS PA
Tel: +1 408 503 2701
Fax: +1 408 503 2912
Mobile: +1 408 472 8097
[EMAIL PROTECTED]
Quality begins with your actions.
_
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza
Sent: Monday, September 10, 2007 12:07 PM
To: arslist@ARSLIST.ORG
Subject: Re: Row level access with flashboards
Hello Jason,
I don't really have an answer to what you are facing but in case you do hear
something about what you have observed, please do let us know. Its a nice to
know sort of thing.. I may have time over this week to simulate what you are
seeing so if you can give me a test case scenario of what you are seeing
I'll check to see if I can replicate that on my free time.
I am however on a slightly different patch level - ARS 7.0.1 P3.. Soon I
intend to upgrade to 7.1 as its a dev/test system, so could check on both
these versions.
Cheers
Joe
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Jason Miller
Sent: Friday, September 07, 2007 6:50 PM
To: arslist@ARSLIST.ORG
Subject: Row level access with flashboards
**
Hi all,
I noticed a strange behavior with flashboards and row level access. I am
working with the OOTB Remedy Support console in ITSM 6. I have added row
level access on the various forms (Help Desk, Change, Task) and those
permissions are pushed to the SHR:ConsolidatedList record.
The problem is if I login as a user who can only see a limited set of
records I still see all of the groups and their record counts in the By
Group flashboard ('Flashboard2'). This user should not have any knowledge of
who the other groups are in the system
Re: Row level access with flashboards
Jason, I think that what you are seeing is as designed. I hold this position because you can control the permissions (at design time) to the Flashboard object. So the developer has to have some ability to expose or hide the data for the targeted users. I think the real difficulty is that statistical information (like Count, Max, Min, etc) might need to be done across all of the application level restrictions for management to really get the whole picture for the business. So I can see a good argument for allowing Flashboards to show such things. However, when the user goes to drill down into the data, then I would think it reasonable for the results to be limited to the portion that the individual user has access too. Example: Flashboard to show number of order that are 4 or more days old that are not yet Sent to the customer. I would think that the President would have enough access to see all order from all departments. So when they drill down they see the whole picture. However a head of a department might only see the orders from their department when they drill down. I would also suspect that the Group By clauses would likely match (very well) to the logical restrictions that the application imposes too. So there likely would only be one department breakdown (er.. Group By element) that a given Department head could drill down on and get a non-zero list. However, I also think there is value in letting the Department heads see the counts for the other departments too. I do see how the design you were expecting could be useful too. I am just not sure how to achieve it short of making Flashboard a total Run Time calculation. ( Which it is not in the current design.) -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap Pick two. On 9/11/07, Jason Miller [EMAIL PROTECTED] wrote: ** snip I realize that I could update the FB's to query the user's group list but my current mission is to see if I am seeing the as designed behavior or is this a bug. This may be a good gotcha to know about when designing flashboards. Thanks again, Jason ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Row level access with flashboards
It is as designed and not considered a defect. The thing to keep in mind is that the admin user is typically the one doing the query [to be able to see information across multiple permission groups] for the flashboard (as defined at design time), not the user. Thus, since the admin can see all data, all the info is passed into the high level response that Flashboards use for display. As mentioned, the data itself is not available and is protected by row level security when users drill down. It's kind of like if you wrote a program (as root) that listed the users on a UNIX system with the highest disk usage for everyone to see - you would be posting high level information about each user (e.g. disk usage), but the users themselves could not see the actual data that was taking up the space. -David J. Easter Sr. Product Manager, Service Management Business Unit BMC Software, Inc. The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black Sent: Tuesday, September 11, 2007 6:12 AM To: arslist@ARSLIST.ORG Subject: Re: Row level access with flashboards Jason, I think that what you are seeing is as designed. I hold this position because you can control the permissions (at design time) to the Flashboard object. So the developer has to have some ability to expose or hide the data for the targeted users. I think the real difficulty is that statistical information (like Count, Max, Min, etc) might need to be done across all of the application level restrictions for management to really get the whole picture for the business. So I can see a good argument for allowing Flashboards to show such things. However, when the user goes to drill down into the data, then I would think it reasonable for the results to be limited to the portion that the individual user has access too. Example: Flashboard to show number of order that are 4 or more days old that are not yet Sent to the customer. I would think that the President would have enough access to see all order from all departments. So when they drill down they see the whole picture. However a head of a department might only see the orders from their department when they drill down. I would also suspect that the Group By clauses would likely match (very well) to the logical restrictions that the application imposes too. So there likely would only be one department breakdown (er.. Group By element) that a given Department head could drill down on and get a non-zero list. However, I also think there is value in letting the Department heads see the counts for the other departments too. I do see how the design you were expecting could be useful too. I am just not sure how to achieve it short of making Flashboard a total Run Time calculation. ( Which it is not in the current design.) -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap Pick two. On 9/11/07, Jason Miller [EMAIL PROTECTED] wrote: ** snip I realize that I could update the FB's to query the user's group list but my current mission is to see if I am seeing the as designed behavior or is this a bug. This may be a good gotcha to know about when designing flashboards. Thanks again, Jason ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Row level access with flashboards
Hello Jason, I don't really have an answer to what you are facing but in case you do hear something about what you have observed, please do let us know. Its a nice to know sort of thing.. I may have time over this week to simulate what you are seeing so if you can give me a test case scenario of what you are seeing I'll check to see if I can replicate that on my free time. I am however on a slightly different patch level - ARS 7.0.1 P3.. Soon I intend to upgrade to 7.1 as its a dev/test system, so could check on both these versions. Cheers Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Jason Miller Sent: Friday, September 07, 2007 6:50 PM To: arslist@ARSLIST.ORG Subject: Row level access with flashboards ** Hi all, I noticed a strange behavior with flashboards and row level access. I am working with the OOTB Remedy Support console in ITSM 6. I have added row level access on the various forms (Help Desk, Change, Task) and those permissions are pushed to the SHR:ConsolidatedList record. The problem is if I login as a user who can only see a limited set of records I still see all of the groups and their record counts in the By Group flashboard (‘Flashboard2’). This user should not have any knowledge of who the other groups are in the system and their ticket volumes. I know the row level permissions are working on the SHR:ConsolidatedList form (also where the FB data is coming from) because the user only see the correct records in the table field. Do flashboards recognize row level access? Is this a bug? As designed? Thanks, Jason ARS 7.00.01 p2 ITMS 6 CMDB 1.1 p3 MS SQL App/DB/MT on Win 2003 IIS 6 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.485 / Virus Database: 269.13.14/999 - Release Date: 9/10/2007 5:43 PM ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Row level access with flashboards
Interesting question!!
I'm on 7.0.1 Patch 1, and did some testing with the HPD:Incident
Management Console (and the management view within), and taking API+SQL
Traces, the queries executed as defined by FB Variables, without any
extra sql attached, (Field 1, 3, 112, 6... restrictions)
It also executes as the user context 'Mid-tier', which is the internal
account, so it might be thought of as an Administrator level account.
I was hoping to find an Impersonate User entry in the API Log, but
alas, none was found. (hum, that IS logged right??)
I DID see where Mid-Tier was getting the user's group list, etc but
nothing was in the SQL Query.
I will (as Joe is going to do as well), perform some additional testing,
because that is an interesting conundrum of data-access...
Thanks-n-advance;
HDT Platform Incident / Problem Manager Architect
Robert Molenda
IT OS PA
Tel: +1 408 503 2701
Fax: +1 408 503 2912
Mobile: +1 408 472 8097
[EMAIL PROTECTED]
Quality begins with your actions.
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza
Sent: Monday, September 10, 2007 12:07 PM
To: arslist@ARSLIST.ORG
Subject: Re: Row level access with flashboards
Hello Jason,
I don't really have an answer to what you are facing but in case you do
hear something about what you have observed, please do let us know. Its
a nice to know sort of thing.. I may have time over this week to
simulate what you are seeing so if you can give me a test case scenario
of what you are seeing I'll check to see if I can replicate that on my
free time.
I am however on a slightly different patch level - ARS 7.0.1 P3.. Soon I
intend to upgrade to 7.1 as its a dev/test system, so could check on
both these versions.
Cheers
Joe
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Jason Miller
Sent: Friday, September 07, 2007 6:50 PM
To: arslist@ARSLIST.ORG
Subject: Row level access with flashboards
**
Hi all,
I noticed a strange behavior with flashboards and row level
access. I am working with the OOTB Remedy Support console in ITSM 6. I
have added row level access on the various forms (Help Desk, Change,
Task) and those permissions are pushed to the SHR:ConsolidatedList
record.
The problem is if I login as a user who can only see a limited
set of records I still see all of the groups and their record counts in
the By Group flashboard ('Flashboard2'). This user should not have any
knowledge of who the other groups are in the system and their ticket
volumes.
I know the row level permissions are working on the
SHR:ConsolidatedList form (also where the FB data is coming from)
because the user only see the correct records in the table field.
Do flashboards recognize row level access?
Is this a bug?
As designed?
Thanks,
Jason
ARS 7.00.01 p2
ITMS 6
CMDB 1.1 p3
MS SQL
App/DB/MT on Win 2003
IIS 6
__20060125___This posting was submitted with HTML in
it___
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the
Answers Are
