@gcusello  Thank you for all of your help!  I apologize for the lag in responding to you.  I have been very busy on another project.  Your suggestion was spot-on, though, so I wanted to be sure to thank you for your assistance.

I had been struggling with the same problem. After a lot of experimentation with different ideas and inspecting SAML payloads. My two main findings as best as I can tell are: When you configure a Google Groups mapping in Google SAML configuration, Google will send the group name as an attribute identically to if it were an attribute set up in the attribute mapping. When Splunk receives a SAML assertion with a role attribute, I think it will try to match it against roles as well as SAML groups. Though in my case all of the role attributes I use are SAML group names, so I cannot confirm that it will match the "role" attribute against an actual role name. But also crucially, when you update Google SAML configurations, it can take 5-10 minutes for the update to "go live". So watch the SAML assertions that you are actually sending to Splunk as you experiment, because otherwise you'll make a changes and even if you get it right it'll appear to not work, you'll make more changes, and suddenly things work, but actually the working configuration was n attempts ago, and it will break itself as it slowly updates to your later configuration attempts, and all you'll know is that something you tried at some point over the last however long was correct. So the net result: Set the "App attribute" to "role", exactly like you did in your screenshot. If you have created a role in splunk whose name is the same as your Google group, you're done. If your Google group has a different name than your role, then set up a SAML group in Splunk with the same name as your google group and assign it the role you want. Splunk will lowercase the group name, that's fine, it'll still match. As a result, you can actually use both (e.g. a group to grant "user" access, and individual user attributes to grant admin access) In my case, I already had a Google group called "Engineering" that I wanted to set up with the "user" role. Here are my configs: Splunk: 1. Configure SAML groups with names corresponding to your Google groups 2. Configure your Google SAML configuration. If you plan to use both user attributes and Google groups, set both a user attribute and a Group membership, both pointing to the "role" App attribute. If you only plan on using groups, you can omit the user attribute. In my case, as you can see from my Splunk config above, I want the "Engineering" google group to all have "user" access to Splunk: 3. If you want to specify role overrides, set them as you did before: 4. If it isn't working, decode and review the SAML assertion that Splunk is receiving. It can take a surprisingly long time for changes made in Google's SAML configuration to go "live". You will likely observe that you're passing along a SAML assertion that does not reflect your most recent Google configuration changes -- if that's the case, just wait a while and try again in a bit.

_json is the generic format that's applied to events if Splunk notices them as being JSON so it's not the best idea. It's best to be as specific as possible with your definition. (ideally sourcetype should have a set of parameters responsible for proper breaking and time recognition defined - so called Great Eight). So while _json is fairly generic you should have your specific settings for - for example - time extraction. Another thing is that even though the format of the event might just be JSON, specific sourcetypes can have different additional aliases or calculated fields defined (for example for CIM compliance). So you want to have your events "pinned" to the specific sourcetype instead of the generic _json.

Well, I think the part I’ve misunderstood is via normal props.conf rules  I thought all events that the transform is applied to was about the real transform (ie the REGEX + FORMAT ) so I didn’t understand why non-matching events (as per REGEX) would get cloned too. Now I get it, I’ll try and find a way to work around that later. About the cloning of _json into a new sourcetype and using that clone into my config, what would be the gain (apart for best practice’s sake) ?