Policies


Policies check identities for certain conditions that are unwanted of even considered dangerous. Such a condition can be a set of roles that should not be combined in a single identity (e.g. “payment preparation” and “payment approval”), two conflicting values of a multi-valued attribute, or even cross-application combinations of permissions.




How do policies work?


Policies are evaluated per identity. 

The evaluation triggers :
  • during aggregation   
  • during identity cube refresh
  • during LCM access request process. 
  • Evaluation during aggregation or identity cube refresh is a so called detective way of finding violations. 
  • Evaluation during LCM access request is called a preventive way of finding violations as they finding violations in this stage may prevent assigning conflicting access rights.
  • Policies are defined specifically for your environment using data from your environment :       

        - Identity attributes  

       - Application attributes                                                                                

       - Risk   scores                                                                                

       - Roles                      

       - Entitlements 

  


Detective Policy Evaluation   For evaluation during aggregation, the option “Check active policies” must be selected.                                                                                                                      


Preventive Policy Evaluation   When the lifecycle manager module (LCM) is  installed, IdentityIQ can check for policy violations as soon as the request is submitted. Out of the box business processes like LCM Provisioning (used for access requests) and LCM Create and Update (used for creating and editing identities) have options to control the policy checking during requests.






Types of Policies


IdentityIQ has six types of policies, 


  • Role SOD Policy  :   This policy type checks for any conflicting roles that an identity could have.
  • Entitlement SOD Policy  :    This policy type checks for conflicting entitlements within an application or across applications. This is quite similar to the Role SOD Policy, but for values of application attributes marked as entitlement in the application schema.
  • Activity Policy :  An activity policy scans activity data for specific events, with the option to select time frames, source and target applications, and more.
  • Account Policy :  Account policies only have a single policy rule: they simply check whether an identity has multiple accounts on an application.
  • Risk Policy :  Risk policies check for any identity with a composite risk score equal to or higher than the configured threshold. Like the account policy, this type of policy will only have a single policy rule.
  • Advanced Policy :   An advanced policy handles situation where the other types do not suffice. The advanced policy can contain multiple types of rules which allows for greater flexibility.