<title>The  definitive  guide  to  TM1  Security  with  examples</title>    The  security  in  TM1  is  one  of  those  things  that  can  make  a  TM1  administrator  go  crazy  over  new  requirements  or  over  new  user  setup.  Things  do  not  get  better  with  reading  the  documentation,  which  does  not  cover  all  aspects  or  it.  This  situation  leads  to  some  common  misconceptions  that  are  uncovered  too.  In  the  following  post,  the  TM1  security  is  peeled  layer-­‐by-­‐layer  starting  from  the  very  basics  of  cube  security  and  finished  with  multi-­‐layer  multi-­‐group  security  setup.    Let`s  start  with  an  excerpt  from  the  documentation  describing  the  different  access  privileges  just  to  be  sure  that  everyone  is  one  page.  

The  object-­‐level  security  rights  for  TM1  groups  are:  

• Admin  -­‐  Group  has  complete  access  to  a  cube,  element,  dimension,  or  other  object.  

• Lock  -­‐  Group  can  view  and  edit  a  cube,  element,  dimension,  or  other  object  and  can  permanently  lock  objects  to  prevent  other  users  from  updating  them.  

• Read  -­‐  Group  can  view  a  cube,  element,  dimension,  process,  or  chore,  but  cannot  perform  operations  on  the  object.  

• Reserve  -­‐  Group  can  view  and  edit  a  cube,  element,  dimension,  or  other  object,  and  can  temporarily  reserve  objects  to  prevent  other  users  from  updating  them.  

• Write  -­‐  Group  can  view  and  update  a  cube,  element,  dimension,  process,  or  chore.  

• None  -­‐  Group  cannot  see  a  cube,  element,  dimension,  process,  or  chore,  and  cannot  perform  operations  on  the  object.  

Sample  TM1  model  used  in  this  post    For  the  purpose  of  explanation  the  following  TM1  model  will  be  used  (as  seen  by  ADMIN):  

 

   Cubes  A,  B  and  C  are  the  same  and  have  two  dimensions:  Dimension  A  and  Dimension  B.    Dimension  A  is  comprised  of  two  elements:  Element  A1  and  Element  A2;  Dimension  B  is  comprised  of  two  elements:  Element  B1  and  Element  B2.  

 The  TM1  model  is  deliberately  made  as  simple  as  possible  so  that  it  does  not  stand  in  the  way  of  understanding  the  actual  security  model.      

Single  Group  Setup    Group-­‐User  relationships    Security  is  applied  on  per-­‐group  basis,  not  on  per-­‐user  basis.    This  does  not  mean  that  there  cannot  be  user  specific  security  setups  as  a  group  can  have  only  one  user  assigned  to  it.    One  user  assigned  to  a  group:  

Multiple  users  assigned  to  a  single  group:    

   In  the  two  cases  above,  all  users  assigned  to  the  Group  A  would  have  identical  privileges.  Note:  for  the  example  above  assume  that  there  is  no  Group  B,  thus  Client  AB  is  assigned  only  to  Group  A.      

Security  Privileges   Group  A   Client  A  

Security  Privileges   Group  A  Client  A  

Client  AB  

Example  1:  Simple  case  with  no  overlap  Adding  the  first  layer  of  security  -­‐  Cubes:  Client  A  is  assigned  exclusively  to  Group  A.  

   The  model  as  viewed  by  Client  A:  Cube  A:  Visible  and  has  WRITE  access  Cube  B:  Visible  and  has  READ  access  Cube  C:  Not  visible.  

 

Security  privileges  relationships  within  one  group  It  is  important  to  mention  that  security  privileges  within  one  group  might  be  overlapping  i.e.  a  cell  can  be  defined  by  cube,  dimension  and  elements  security  at  the  same  time.    If  you  apply  different  security  rights  to  the  objects  that  identify  a  cell  of  data,  TM1  applies  the  most  restrictive  security  right  to  the  cell.      For  example,  a  user  has  READ  access  to  a  cube  and  WRITE  access  to  the  elements  in  this  cube.  In  this  scenario,  the  READ  access  of  the  cube  overrides  the  WRITE  access  of  the  elements,  and  the  user  can  view  cube  data  but  cannot  update  the  cube  data.    If  the  above  scenario  is  reversed  i.e.  a  user  has  WRITE  access  to  a  cube  and  READ  access  to  the  elements  of  this  cube,  then  READ  access  would  still  apply,  and  the  user  can  view  cube  data  but  cannot  update  the  cube  data.    The  key  thing  to  note  here  is:  Dimension  security  does  not  directly  affect  data  security;  NONE  access  does  restrict  a  user  from  seeing  a  dimension  hence  cube  hence  data.  From  one  side,  there  is  no  difference  between  READ  and  WRITE  and  ADMIN  access  privileges  for  data  access;  on  the  other  side,  it  applies  different  rights  in  terms  of  attributes  and  formatting.    The  only  exception  is  cell  security,  which  overrides  everything  else.  

   

Combined  lowest  privelege  

Cubes  security  

Dimensions  (NONE  or  ELSE)  security  

Element  security  

Example  2:  Overlapping  privileges  within  one  group  In  this  example,  we  have  all  layers  of  security  except  cell  level  security:  Cubes   Dimensions   Elements  

 

 

 In  the  following  example  READ  overrides  WRITE  for  Elements/Cubes.  

 Cube  B  is  still  READ  despite  the  fact  that  Element  A2  /  Element  B2  is  specified  as  WRITE.  

   

To  eliminate  the  variable  of  dimension  security,  the  next  setup  will  switch  elements  around:  Cubes   Dimensions   Elements  

 

 

 

 Cube  B  is  still  READ  despite  the  fact  that  Element  A1  /  Element  B1  is  specified  as  WRITE.      Making  a  change  to  dimension  security  makes  users  unable  to  see  the  cubes  that  use  the  dimension:  

     

Multiple  Groups  Setup  

A  user  who  is  a  member  of  multiple  groups  receives  the  highest  level  of  rights  from  all  groups.  

For  example,  in  the  sample  data,  a  user  is  a  member  of  two  groups.  

• Even  Numbers,  which  has  WRITE  access  to  the  CostCentre2  and  CostCentre4  elements  in  the  Cost  Centre  dimension,  and  READ  access  to  the  other  elements  in  the  Cost  Centre  dimension.  

• Odd  Number,  which  has  WRITE  access  to  the  CostCentre1  and  CostCentre3  elements  in  the  Cost  Centre  dimension,  and  READ  access  to  the  other  elements  in  the  Cost  Centre  dimension.  

TM1  gives  this  user  WRITE  access  to  CostCentre1,  CostCentre2,  CostCentre3  and  CostCentre4,  and  READ  access  to  the  other  elements  in  the  Cost  Centre  dimension.  

   

TM1  approach  to  security  privileges  overlap  within  one  group  and  then  nested  onto  multiple  groups  as  follows:  

Assuming  Blue  quadrant  is  what  is  setup  in  TM1  object  per  object.  

Yellow  quadrant  is  what  we  actually  have  in  TM1  before  combining  groups:  i.e.  applying  the  lowest  privileges  first.    

Green  quadrants  are  derived  the  highest-­‐then-­‐lowest  way  i.e.  combining  group  privileges  first  i.e.  applying  the  highest  privileges  first,  and  only  then  applying  the  most  restricted.  

In  other  words,  the  correct  order  is  1-­‐3-­‐4.  

1-­‐2-­‐4  would  yield  wildly  different  results  and  it  is  NOT  used  by  TM1.  

1.  Objects     Group  A   Group  B   3.  Objects   Group  A+B  Cube  A   WRITE   NONE   Cube  A   WRITE  Cube  B   READ   NONE   Cube  B   READ  Cube  C   NONE   WRITE   Cube  C   WRITE                      Dimension  A   WRITE   WRITE   Dimension  A   WRITE  Dimension  B   WRITE   WRITE   Dimension  B   WRITE                      Element  A1   WRITE   READ   Element  A1   WRITE  Element  A2   WRITE   READ   Element  A2   WRITE  Element  B1   READ   WRITE   Element  B1   WRITE  Element  B2   READ   WRITE   Element  B2   WRITE  2.  Output   Group  A   Group  B   4.  Output   Group  A+B  Cube  A   READ   NONE   Cube  A   WRITE  Cube  B   READ   NONE   Cube  B   READ  Cube  C   NONE   READ   Cube  C   READ                      Dimension  A   READ   READ   Dimension  A   WRITE  Dimension  B   READ   READ   Dimension  B   WRITE                      Element  A1   READ   READ   Element  A1   WRITE  Element  A2   READ   READ   Element  A2   WRITE  Element  B1   READ   READ   Element  B1   WRITE  Element  B2   READ   READ   Element  B2   WRITE      

Example  4:  Simple  multi-­‐group  setup  In  this  example  the  groups  are  very  similar  in  setup,  the  only  difference  is  Dimension  A.  Group  A  has  WRITE  Access  to  A1,%  Group  B  has  WRITE  access  to  A2.  Cubes   Dimensions   Elements  

 

 

   Client  A  /  Cube  A   Client  B  /  Cube  A   Client  AB  /  Cube  A  

     

Client  AB  has  access  to  both  Elements  A1  and  A2  i.e.  element  by  element  the  highest  privilege  was  picked.    

Example  5:  Multilayer  multi-­‐group  setup  In  this  example  the  groups  are  different  in  setup  and  neither  of  the  groups  has  WRITE  access  to  the  Cube  A  data.  Once  combined,  it  is  applying  highest  privileges,  making  the  setup  counterintuitive.  Dimensions  are  kept  simple  and  are  out  of  this  equations.  Cubes   Dimensions   Elements  

   

 

   Client  A:  As  per  the  setup,  Client  A  has  access  to  both  Dimensions  A  and  B  and  cubes  A  and  B.  Server  explorer  view:  

 Checking  further:  

 Conclusion:  Client  A  does  not  have  write  access  to  any  of  the  cubes.    Client  B:  As  per  the  setup,  Client  A  has  access  to  both  Dimensions  A  and  B  and  cubes  A  and  B.  Server  explorer  view:  

 

Checking  further:  

 Conclusion:  Client  B  does  not  have  write  access  to  any  of  the  cubes.    Client  AB:  As  per  the  setup,  Client  A  has  access  to  both  Dimensions  A  and  B  and  cubes  A  and  B.  Server  explorer  view:  

 

   Conclusion:  Neither  Group  A  nor  Group  B  have  WRITE  access  to  anywhere  in  the  model,  while  the  combination  has  WRITE  access  to  any  of  the  cubes,  yet  the  combination  of  the  two  yields  counterintuitive  but  valid  result  –  Cubes  A  and  C  are  writeable.