Event Details - what does the GUID represent and can I query that?

[mcheek (Mark Cheek)]

I am trying to see if there’s a way of ‘peeling back the onion’ on audit events around source updates. So, two questions:

1. Does anyone know the specific source modifications that trigger the event “Update Source Passed”? For example, changing the source owner does not trigger it but adding a field to the account schema does

2. What does the GUID in the “details” attribute represent in this event payload? Is there a way I can query it?

{
        "org": "chk",
        "pod": "prd04-useast1",
        "created": "2023-05-09T21:48:06.490Z",
        "id": "0f3523024c143bf4eb710955cbc6dadd30b761b37d516b9a5ee1d637d9807356",
        "action": "SOURCE_UPDATE",
        "type": "SOURCE_MANAGEMENT",
        "actor": {
            "name": "452570"
        },
        "target": {
            "name": "SAP BW ABAP [source]"
        },
        "stack": "diana",
        "details": "9e9a5fa179bc4497818074c71d784e02",
        "attributes": {
            "sourceId": "source",
            "sourceName": "SAP BW ABAP"
        },
        "objects": [
            "SOURCE"
        ],
        "operation": "UPDATE",
        "status": "PASSED",
        "technicalName": "SOURCE_UPDATE_PASSED",
        "name": "Update Source Passed",
        "synced": "2023-05-09T21:48:06.615Z",
        "_type": "event",
        "_version": "v7"
    }

[colin_mckibben]

@mcheek

Does anyone know the specific source modifications that trigger the event “Update Source Passed”? For example, changing the source owner does not trigger it but adding a field to the account schema does

I asked our PM for sources if he knows the answer to this. He’s away on vacation so I won’t have a response of a week or so.

@mcheek

What does the GUID in the “details” attribute represent in this event payload? Is there a way I can query it?

That’s a pretty vague attribute name. It looks like a GUID of some sort. Is that the GUID for the SAP BW ABAP source?

[colin_mckibben]

@mcheek

Does anyone know the specific source modifications that trigger the event “Update Source Passed”? For example, changing the source owner does not trigger it but adding a field to the account schema does

There doesn’t seem to be any definitive documentation on what triggers the source update event. However, if you aren’t seeing an event based on an action you performed, can you please submit an idea?

[mcheek (Mark Cheek)]

I opened a ticket with support for this question and they basically said “no such documentation exists”. We’re you ever able to get any info from that PM?

[colin_mckibben]

Unfortunately, it’s the same response. We don’t have comprehensive documentation on every audit event, but if you think an action should trigger an event, but it doesn’t, you can always submit an idea.

[mcheek (Mark Cheek)]

That’s fine… our auditors want some sort of validation that our sources haven’t been changed from one audit to another (without documented testing and change management records), and I was hoping to use SOURECE_UPDATE_PASSED in a report they can consume, but I worry about changes that aren’t material to how the source is configured triggering an event and having an auditor ask me what changed, and then me not being able to tell them what exactly triggered that audit event.

[RTASB (Rishabh Thukral)]

Hi,

Was there ever an idea submitted for this? Seems like a pretty big miss from an audit perspective to not log what was changed as part of a source update event. Or if it is logged, then missing a mechanism to retrieve it.

We are currently in a situation where a source config was changed, and the resource that made the change is away so we don’t know what was changed exactly except for a meaningless GUID string in the details.

[mcheek (Mark Cheek)]

To be honest, submitting an idea feels like such a long shot to get something to happen… I don’t have a ton of confidence in seeing items on the board get rolled out into actual features. There are highly popular feature requests that have been out there for YEARS without much idea of when they could possibly be released

I agree with you though, I don’t want to be in a similar situation as you with no idea how to find out what was changed.

[colin_mckibben]

A lot of people have this sentiment regarding the ideas portal, and I certainly understand where the frustration comes from. There are a ton of ideas and not enough time/resources to implement them all. They also have to compete with planned roadmap items. But I still encourage anyone who has an idea to submit it to the portal. It’s easier for me to advocate for ideas when I have actual customers voting and commenting on ideas. If you don’t create an idea, then it almost certainly won’t make it into the product.

Looking at the status of all ideas, it’s not great but there is progress being made.

[mcheek (Mark Cheek)]

This is nit-picky, but the numbers you’re showing are for all products and not just IDN.

From a customer perspective, it’s hard to have a ton of confidence when there just isn’t much information for us to consume from this board. It doesn’t seem like popular ideas have regular updates from whoever on the SailPoint side owns it. Not to mention, some of the most popular ideas out there have been there for over two years and only a handful are on the roadmap. I’ve used A-Ha! briefly when we owned it here, and it seems like a very powerful platform for product management. I feel like there could be some improvements to help us on the customer side have a better experience. Something simple like “once a quarter we will provide status updates on the top x% of popular ideas”

There are a ton of ideas and not enough time/resources to implement them all.

That’s exactly the point… why would I even bother putting an idea out there if there are so many out there and even the most popular ones aren’t getting shipped?

[mcheek (Mark Cheek)]

@RTASB

Seems like a pretty big miss from an audit perspective to not log what was changed as part of a source update event. Or if it is logged, then missing a mechanism to retrieve it.

Yeah, and because of this I’m having to regularly meet with auditors to review every single SOX-Relevant source configuration to demonstrate what it does and why we consider it to be complete and accurate.

It sure seems to me that the information is out there, but nobody seems to be able to tell me the answer.

If we knew that the audit events were only triggered on configuration changes that affect the data they ingest, then we could rely on these audit events to say when the sources were modified, but still couldn’t tell you what was modified.

[mcheek (Mark Cheek)]

Hey @colin_mckibben it looks like the “details” field corresponds to the Slpt-Request-Id response header whenever you make a source update. Is that something that’s traceable?

(FYI for @RTASB )

[mcheek (Mark Cheek)]

Going further down the rabbit hole…

Thinking the information behind Slpt-Request-Id wouldn’t be public, I thought that I could possibly just use the Source Update Trigger to then Run an export-sp-config Job to store that config somewhere, essentially doing a DIY version history.

However, even though there are SOURCE_UPDATE audit events fired when I make config changes to a source, that trigger is not firing. That includes what I consider “non-material” updates like name, description, owner but also more important attributes like the domain distinguished name or the user search scope. Those all trigger events in the audit table, but not the “Source Updated” trigger.

I could only get the trigger to fire when I did things like update the account schema, and I saw the corresponding audit event was far more helpful in this case. It makes me wonder why there is inconsistency in why the trigger isn’t firing on all audit events, when it seems to clearly be positioned to do that

{
        "org": "chk-sb",
        "pod": "stg02-useast1",
        "created": "2023-09-07T14:07:21.085Z",
        "id": "916885fd338093796f78de585632cf785fdc6a77f1764ecbe59b5da30553e050",
        "action": "SchemaUpdated",
        "type": "SOURCE_MANAGEMENT",
        "actor": {
            "name": "366088"
        },
        "target": {
            "name": "account"
        },
        "stack": "diana",
        "trackingNumber": "bd5f9647dbcb470aa57ff5a10605891e",
        "attributes": {
            "addedAttributes": "[\"CHKbuilding\"]",
            "changeset": "[\"attributes added was added with value [CHKbuilding]\"]",
            "sourceId": "source",
            "sourceName": "AD Cloud Admin Users"
        },
        "objects": [
            "SOURCE",
            "SCHEMA"
        ],
        "operation": "UPDATE",
        "status": "PASSED",
        "technicalName": "SOURCE_SCHEMA_UPDATE_PASSED",
        "name": "Update Source Schema Passed",
        "synced": "2023-09-07T14:07:21.382Z",
        "_type": "event",
        "_version": "v7"
    }

@colin_mckibben to your knowledge, should the Source Updated trigger be firing anytime there’s a SOURCE_MANAGEMENT audit event?

[RTASB (Rishabh Thukral)]

Thanks heaps for looking into this in such details. Would you have documented the list of source update events that did fire the trigger versus the ones that didn’t?

[mcheek (Mark Cheek)]

Honestly, I didn’t want to take the time to do that. SOURCE_UPDATE_PASSED was the important one to me that was not working, but I did notice that operations like SOURCE_SCHEMA_UPDATE_PASSED.

If you look at the other topic I posted about this, you’ll see that engineering identified it as a bug and are currently working on it.