Jump to content

API Auditing Enhancement


Sarge

Recommended Posts

Hiya,

 

Not sure if this is possible, I believe it maybe possible already but my WebAPI-fu is too limited, but it would be nice to pass a "reason" through the WebAPI headers.
EG: $ExecutePwdStateIPACall = Invoke-Restmethod -Method GET -Uri $PwdStateIPAURL -Header @{ "APIKey" = "abcdefg1234567hijklm89101112" , "Reason" = "Script Name: List of VMs"}


The 'reason' would then be added to the auditing data description of WebAPI connections. Making it easier to see at a glance why a connection was made and if it was expected.
In the below screenshot I have a few entries, all of which are from the same IP address for the same password, I expect to see this - but I'd like to be able to tell which script it was that made the connection - as this host runs about a dozen scripts per day all with repeating schedules every few hours (in one case, every 5 minutes...which is how I came across this enhancement request because it appears to not running anymore lol)

5a7268761d322_ScreenShot2018-02-01at11_17_17am.thumb.png.cb8c1fbb13c8313971bbde3a8134e599.png

Link to comment
Share on other sites

  • 2 months later...
  • 3 months later...
  • 2 weeks later...
  • 2 weeks later...
On 7/26/2018 at 11:10 AM, support said:

Coming in the next release :)

 

And now to be annoying. Can it be set on a per password list setting as a requirement?
IE: No reason provided, then data isn't returned. I should have included that request earlier lol

Link to comment
Share on other sites

Hi Sarge,

 

We believe in the software industry this is called "scope creep" :)

 

If we were to add this as a standard setting on the 'Password List Details' tab, then it will be quite a bit of work - as settings can be cloned from other Password Lists, and Templates, the API would need to provide cater for this also when adding Password Lists, cloning folders would need to be updated, etc, etc.

 

Instead, what if we added this as a option on the screen below? it's the logical place to put it, but would not require all the work mentioned above, as the API Tab settings here do not get "cloned" from anywhere.

 

apikeytab.png

 

Regards

Click Studios

 

Link to comment
Share on other sites

3 hours ago, support said:

We believe in the software industry this is called "scope creep" :)

 

Happens to us as well, isn’t it great lol

 

3 hours ago, support said:

Instead, what if we added this as a option on the screen below? it's the logical place to put it, but would not require all the work mentioned above, as the API Tab settings here do not get "cloned" from anywhere.

 

That’s actualky the spot I was thinking when I was writing the post. I agree it’s most logical there. 

Link to comment
Share on other sites

Just thought of something for this Sarge.

 

Let's say one Password List is configured where 'Reason' is mandatory, and we are searching across all Password Lists without a reason being specified. Do you think we should raise an exception, and break the API Call, or simply not return any records from that one Password List. Not returning records may cause some confusion for customers, but these are the only two possibilities I can think of.

 

Thoughts?

Regards

Click Studios

Link to comment
Share on other sites

22 hours ago, support said:

Let's say one Password List is configured where 'Reason' is mandatory, and we are searching across all Password Lists without a reason being specified. Do you think we should raise an exception, and break the API Call, or simply not return any records from that one Password List. Not returning records may cause some confusion for customers, but these are the only two possibilities I can think of.

 


I hadn't thought of that; but I think breaking the API call maybe the best option; with an exception message similar to "One or more targeted password lists require auditing data".

Confusing the customers should be avoided. As long as the exception message is clear why the API call failed then I see no issues with it. Perhaps return the password list ID(s) that the API call failed on in the exception message.

Also, log the API call exception in the password list auditing data table?

Link to comment
Share on other sites

  • 2 weeks later...

One more question on this Sarge.

 

We're also adding in new methods to manage permissions on Folders, Password Lists and Password records - see below. If this 'Mandatory Reason' option is set at the Password List level, do you think it should also be required for the new 'Permission' methods as well?

 

apireasonpermissions.png

 

Regards

Click Studios

Link to comment
Share on other sites

Hi Sarge,

 

For now, we are going to make this consistent with how the UI works i.e. the Mandatory option is not applicable for managing permissions. You can still provide a reason, and it will be added to auditing data, but it's not mandatory for now.

Regards

Click Studios

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...