Logging SAML SSO authentication data for enterprise and org audit log events - [Beta Feedback]

[boylejj]

Private Beta Available Now!

Summary

SAML single sign-on (SSO) gives organization owners and enterprise owners a way to control and secure access to organization resources like repositories, issues, and pull requests. Organization owners can invite your personal account to join their organization that uses SAML SSO, which allows you to contribute to the organization and retain your existing identity and contributions on GitHub.

When you access resources within an organization that uses SAML SSO, GitHub will redirect you to the organization's SAML IdP to authenticate. After you successfully authenticate with your account on the IdP, the IdP redirects you back to GitHub, where you can access the organization's resources.

The purpose of this feature is to augment existing audit log events with the SAML identity associated with the organization. In doing so, enterprise and organization administrators will be able to track account activity associated with a specific SAML identity.

Intended Outcome

Enterprise and Organization owners will be able to track audit log activity associated with specific SAML SSO identities. By providing the SAML SSO identity as part of the audit log, enterprise and organization owners can quickly and easily link logs from multiple sourcing using the same SAML SSO identity identifiers.

How will it work?

The external_identity_nameid or external_identity_username will be displayed in all audit log events where the SAML SSO identity was used as a means of authentication.

[emtunc]

Firstly, THANK YOU. This is awesome and solves the longstanding problem of "who in the world is userX?!" and now properly allows us to link GH handles to proper corporate identities in our logs.

Secondly, is there a technical reason to not add the external_identity_* to events where the actor is present but not necessarily triggered via SAML/SSO?

e.g., actorX did a bad thing with a token - the actor is present in the audit log but it looks like the external_identity isn't. Having the external_identity would better help us tell a full story (user did X, Y and Z from their local machine using a PAT/SSH key and then went on to do A, B and C in the UI)

[timhirsh]

Thanks @boylejj, I'm looking forward to this as well. Just another data point that I've observed.. events that are missing the external_identity_* fields typically have a programmatic_access_type value specified. I would expect programmatic access types such as Personal access token (classic) & OAuth access token to include external identity info as well.

[emtunc]

@boylejj any updates on this? The Google Chronicle team have updated their GitHub parser to take these new fields into account but I'm finding most of my logs don't contain the external identifier which is leaving me blind to events that I would like to capture and/or write rules against.

It would be very valuable to have the external identity associated with all events that can be linked back to a particular GitHub user - i.e., where the GitHub username is present, the expectation is that the external identifier is present also.

[boylejj]

@emtunc We are actively working on this with a target of deploying the updated solution this quarter. Supporting this feature is necessitating some data model updates, which is making the change more complex than SSO activity in the web U/I that already has an active SAML session.

[boylejj]

@emtunc, @timhirsh, and @larrys, we just shipped an update to the private beta participants that makes the external_identity_* fields available for token authenticated events, except for token authenticated git events. Note, this data will only be present for new events that have happened since the feature was enabled for your enterprise. It will not go back and populate this data for past events.

Can you take a look and let me know if you have additional feedback?

[wiredaem0n]

Not sure if this ever got resolved, but at the moment I see the new fields external_identity*_ in some of the audit logs but not all. At the moment I noticed the following event type are comming without it

{ "@timestamp": 1763591456699, "_document_id": "PHZ1IaXicqqWVBFUSpBzlA", "action": "api.request", "actor": "github-user", "actor_id": xxxxxxxxxx, "actor_is_bot": false, "application_name": "Visual Studio Code", "business": "acme", "business_id": 77777, "created_at": 1763591456699, "filtered_request_body": { "operationName": "MergeQueueForBranch", "query": "query MergeQueueForBranch {\n repository(owner: \"\u003cREDACTED\u003e\", name: \"\u003cREDACTED\u003e\") {\n mergeQueue(branch: \"\u003cREDACTED\u003e\") {\n configuration {\n mergeMethod\n __typename\n }\n __typename\n }\n __typename\n }\n}" }, "hashed_token": "xxxxxxxx, "integration": null, "oauth_application_id": 797352, "operation_type": "access", "programmatic_access_type": "OAuth access token", "query_string": "query MergeQueueForBranch {\n repository(owner: \"\u003cREDACTED\u003e\", name: \"\u003cREDACTED\u003e\") {\n mergeQueue(branch: \"\u003cREDACTED\u003e\") {\n configuration {\n mergeMethod\n __typename\n }\n __typename\n }\n __typename\n }\n}", "rate_limit_remaining": 4415, "request_access_security_header": null, "request_id": "E449:1D73F2:573A01", "request_method": "POST", "route": "/graphql", "status_code": 200, "token_id": 2101691231xx, "token_scopes": "read:user,repo,user:email,workflow", "url_path": "/graphql", "user": "github-user", "user_agent": "node-fetch/1.0 (+https://github.com/bitinn/node-fetch)", "user_id": xxxxxx }

In short anything it seems that any logs generated from the the api graphql , its just not putting out the field in question.

"request_method": "POST", "route": "/graphql",

Is there a plan to get this up to par ?

[andreaso]

I'm kind of wondering what is supposed to be exposed on an Organization level vs. on an Enterprise account level.

Viewing the audit from the GitHub web interface I can see the View SSO details using both https://github.com/enterprises/FOO/settings/audit-log and https://github.com/organizations/BAR/settings/audit-log.

Yet when using the REST API to query the audit log I only get the external_identity_nameid info when using the /enterprises/{enterprise}/audit-log endpoint. The /orgs/{org}/audit-log endpoint does not appear to contain any SSO info.

Bug or feature?

[boylejj]

@andreaso the behavior you're seeing is a byproduct of how the feature flag is configured. I have confirmed with the engineering team that both API endpoints will have the data as part of the GA release.

[andreaso]

Thanks!

[joelcox22]

Thanks. I'm very much looking forward to this being available in the API as well.

I have prepped the minor changes I think are needed for the steampipe github plugin - turbot/steampipe-plugin-github@main...joelcox22:steampipe-plugin-github:main - looking forward to being able to test that when this feature reaches GA.

[emtunc]

@boylejj could you briefly explain the difference between nameid and username? Would we ever expect the two to differ? In the logs I've seen, they're always the user's email.

[boylejj]

I'll continue to dig into this. What your describing differs from what I saw when testing this earlier today. If you can send me any additional details, it would be super helpful.

[emtunc]

I can send example logs to your email if you can share it?

[craSH]

Hi there, I'm seeing this same behavior, and this issue was the best result I could find that mentioned both of the fields (external_identity_nameid and external_identity_username in our case.. curious note also about the lack of the final underscore present in our logs).

My org does not use EMU, and we are on Enterprise Cloud. Happy to work w/ support and/or our reps if any example logs are needed.

[boylejj]

@craSH, Thanks for reaching out. Responsible PM here. Can you send me some example logs where you're seeing this? I was under the impression we had addressed this problem a while back when it was raised in Nov. 2022.

[craSH]

@boylejj I'll reach out from my work email shortly!

[larrys]

Are there plans to add this to webhooks that get sent (not just the audit records), but regular webhooks. We have a few things that key off of this, and having the org id would be nice.

[larrys]

I have a case where the actor does not match the external_identity_nameid entry. It is for an action of org.remove_member. The actor is who performed it, but the external identity nameid is the user that was removed instead of the saml id.

[boylejj]

@larrys, If you don't mind, I am going to reach out via email to get some additional data from you to investigate this further.

[hernanfbmex]

Hi colleagues. One question and sorry for my ignorance, is there any way to track the progress of this feature? Thank you

[ianwilliams1]

Seems this was recently enabled for my Enterprise.
Q: How can I query the audit-logs for events by "SAML SSO identities".
ie: I can query by actor:githubid or user:githubid,
what about actor:usersamlid@myorg.com or samlid:usersamlid@myorg.com?

[Vargas1205]

728969000018458575