Slice Security vs Conditional Input Finance Business Rule

[miked]

Hi All,

I am wondering if anyone has an opinion on using slice security for specific UD3 level security vs. using a Finance Business Rule to control access to certain UD3 members.  Basically, I am looking to say if a user is in a certain security group, they should not be able to write data to certain UD3 members.  I believe it can easily be written using slice security (Cube Data Access Security) or with a conditional input FBR (if user in g.  I see an advantage to not having to update every entity with turning the Data Access Security to True and potentially adding categories vs with a BR, just writing a rule that doesn't touch metadata.  I tend to typically try to avoid 'touching' existing metadata if I don't have to especially when adding in a Planning Cube next to a pre-existing and well established Consolidation Cube.  Does anyone know if there is any real pro/con to either approach other than less updating of metadata which I mention above?  Would performance factor in or if the security / rules are setup similarly, are they essentially doing the same kind of processing?

Curious,

Mike

[DRusconi]

Hi Mike,

for controlling the access to cube slices based on user security groups, I would prefer the cube Data Cell Access Security settings instead of no input rules in a BR because of their different purposes and, primarily, performance.

I will expose my reasons, but open to hear different opinions from everyone else:

• After having amended the Cube Data Access Security settings and pressed save, the system should create in the background a dictionary of intersections ==> security settings to speed up the rendering of cube views/validation of imported records.
• Data Cell Access Security settings are used to control RW grants to cube slices and are naturally linked to groups and behaviour like user in/not in group, cell in/not in filter.
• Data Cell Conditional Input settings are used to prevent input against certain intersections for any user group. They are part of the cube settings and they are part of the dictionary intersections ==> security settings.
• Conditional Input defined in a Finance BR is the on-the-fly version of cube Data Cell Conditional Input and is used to prevent input against certain intersections based on certain system conditions, such conditions could be static (e.g. a complicate member filter that is easier to write in a rule) or dynamic (e.g. no input based on WF status, flag values in certain intersections etc.). On-the-fly means that when we render a CV every intersection goes through this BR.
• Data Cell Conditional Input or Conditional Input BR can only prevent input, they cannot block access (e.g. the cell value will be always visible). 
• Conditional Input in a BR can check if users belong to specific groups using the methods available from the class BRApi.Security, but every BRApi call is a single connection to the framework DB and this could saturate the channel db server <=> app server (for this reason, in Finance rules, it is suggested to use methods under api class, aka OneStream.Finance.Engine.FinanceRulesApi, because they are all packed within the same db connection).

Apologies for the lengthy answer and for noticing your questions!

Daniele