IC SunsetThe developerWorks Connections platform will be sunset on December 31, 2019. On January 1, 2020, this community and its apps will no longer be available. More details available on our FAQ.
Topic
  • 5 replies
  • Latest Post - ‏2018-11-23T10:06:52Z by franzw
frisalde
frisalde
119 Posts

Pinned topic Auditing provisioning policies modifications

‏2018-06-25T09:48:02Z | audit; enrolehiddensearchattributes policies; provisioning

Dear friends,

when a provisioning policy is modifed for including/excluding a role membership, it can not be seen in the operation audit.

 

Is it enough to remark the erpolicymembership=erpolicymembership entry in the enRoleHiddenSearchAttributes.properties file?.

 

There is another similar entry named ermembership, what is that means?.

 

Btw, I think we will remarked  the erpolicytarget entry too to enrich the provisioning policies audit.

 

From my point of view, this information is very interested to forensic analysis when an authorization is done and it is needed to know how it was done. In additional the space impact in the Database and a bit less performance, from your point of view, are there any reason to be unset by default?.

 

Thanks in advance.

  • frisalde
    frisalde
    119 Posts
    ACCEPTED ANSWER

    Re: Auditing provisioning policies modifications

    ‏2018-06-25T14:57:30Z  

    For your information, the configuration is working as expected.

     

     

    Attachments

  • frisalde
    frisalde
    119 Posts

    Re: Auditing provisioning policies modifications

    ‏2018-06-25T14:57:30Z  

    For your information, the configuration is working as expected.

     

     

    Attachments

  • franzw
    franzw
    519 Posts

    Re: Auditing provisioning policies modifications

    ‏2018-08-03T11:57:12Z  

    I do not understand the reason behind not including the role membership on the default page.... - some of the decisions on how the audit log is working in ISIM are not how I would have done it :-) 

    That said - I like your solution.

    But you are missing an even more important fact - namely the result of you submit. By default ISIM only stores attribute changes on the first level of an transaction (nicely illustrated by your screenshots) - you cannot see what actually see in the audit log what is send to the adapter.

    Luckily there is a solution to that.

    If you add the following on the postscript of all CRUD entity extensions used in your operational workflows, they will log the content :

    WorkflowRuntimeContext.logActivityData(<property>',false);

    where <property> is the property mapping the attribute in question in quotes e.g. "Entity"/"person"/"account" (I am not sure of the case - so remember to check) e.g. : 

    WorkflowRuntimeContext.logActivityData('Entity',false);

    This will store the actual result of what the system does in the sub processes and not only in the root process (PROCESSLOG table - new_data or small_new_data rows as XML strings).

    Be aware that  the logActivityData() method is undocumented and hence unsupported.

    HTH

    Regards

    Franz Wolfhagen

  • frisalde
    frisalde
    119 Posts

    Re: Auditing provisioning policies modifications

    ‏2018-09-20T08:18:25Z  
    • franzw
    • ‏2018-08-03T11:57:12Z

    I do not understand the reason behind not including the role membership on the default page.... - some of the decisions on how the audit log is working in ISIM are not how I would have done it :-) 

    That said - I like your solution.

    But you are missing an even more important fact - namely the result of you submit. By default ISIM only stores attribute changes on the first level of an transaction (nicely illustrated by your screenshots) - you cannot see what actually see in the audit log what is send to the adapter.

    Luckily there is a solution to that.

    If you add the following on the postscript of all CRUD entity extensions used in your operational workflows, they will log the content :

    WorkflowRuntimeContext.logActivityData(<property>',false);

    where <property> is the property mapping the attribute in question in quotes e.g. "Entity"/"person"/"account" (I am not sure of the case - so remember to check) e.g. : 

    WorkflowRuntimeContext.logActivityData('Entity',false);

    This will store the actual result of what the system does in the sub processes and not only in the root process (PROCESSLOG table - new_data or small_new_data rows as XML strings).

    Be aware that  the logActivityData() method is undocumented and hence unsupported.

    HTH

    Regards

    Franz Wolfhagen

    Hi Franzw,

    as usually, an important valuable remark.

    In our case we already had the modify account operation audited (WorkflowRuntimeContext.logActivityData("account",false);).

     

    Best regards.

  • serega_dgl
    serega_dgl
    3 Posts

    Re: Auditing provisioning policies modifications

    ‏2018-11-23T06:21:56Z  

    WorkflowRuntimeContext.logActivityData('Entity',false);

    This will store the actual result of what the system does in the sub processes and not only in the root process (PROCESSLOG table - new_data or small_new_data rows as XML strings).
    http://q-answer.ru/questions/kak-zapustit-powershell-script-7774.html

  • franzw
    franzw
    519 Posts

    Re: Auditing provisioning policies modifications

    ‏2018-11-23T10:06:52Z  

    WorkflowRuntimeContext.logActivityData('Entity',false);

    This will store the actual result of what the system does in the sub processes and not only in the root process (PROCESSLOG table - new_data or small_new_data rows as XML strings).
    http://q-answer.ru/questions/kak-zapustit-powershell-script-7774.html

    I do not think that is accurate - the logActivityData() mthod needs to be called on the every extension writing to the ldap e.g. person add/modify/delete and account add/modify/delete.

    To my knowledge there is is no inheritance - i.e. if you add to a person add extension it will only log the data for the person - not account creations that are performed as part of the enforcePolicyForPerson extension...

    And still remember this is officially not supported - but I do not expect that there is any plans to change the functionality in this area of ISIM.

    Going back to the original question - it would have been nice if  the provisioning policy workflows where part of the operational workflows - but they are not - then the logActivityData() could have been used there to ensure that the provisioning policy changes where accurately logged in the data base tables (as XML that AFAIK is also not documented - there may be DTD floating around somewhere that includes it - but I have not seen it - but it is so simple anyhow...)

    Regards

    Franz Wolfhagen