Idea: Attribution for Okta

[jkowall]

After discussing the use of this plugin with folks at Okta such as @mbegan they are suggesting we allow the ability to change the user agent header or possibly add another header in the configuration. The reason for this is so Okta can track the user/system which is calling the Okta APIs. We're happy to contribute the code to make this happen.

Open for commentary, or we can submit a PR in a couple of weeks if it sounds good to the maintainers of the project.

[mbegan]

@jkowall thanks!

The best way for me to get what I'm looking for (today) is to have a custom userAgent. Considering how Logzio makes use of this I think it would be good if we had a semi-dynamic and nested userAgent value.

If you added a config and let others (Jonah) provide a "caller" or "configurer" parameter we can then bake out a default and then custom userAgent to send along with requests.

Default SecurityRiskAdvisorsLSP/1.0 (default)

3rd party configured SecurityRiskAdvisorsLSP/1.0 (logz.io)

https://github.com/SecurityRiskAdvisors/logstash-input-okta_system_log/blob/6bf33cc6b00a5cffdae72e89acd121e224ee6ac3/lib/logstash/inputs/okta_system_log.rb#L364

[mbegan]

See https://github.com/mbegan/logstash-input-okta_system_log/commit/542cb660df6831a163d1fff6a6a00ed5c3c553b0 for an idea of what i'm thinking.

[jkowall]

Sounds good to me, lets see what the maintainers say.... or else we can ping if no response in the coming days.

[p-b--]

I like this idea -- I had thought about it when we were originally developing the plugin but never found a good use case for this. A few questions:

1. Versioning for the user agent, I see in your demo, you it set to 1.0, I think setting the version to the active version of the plugin would be more useful.
2. I still hopes that this will be accepted to https://github.com/elastic/logstash/issues/10251, but haven't heard anything. Accordingly, I'm worried about making the UserAgent explicitly tied to any (including our) company name. Would a name like LogstashInputPlugin work as the header?
3. Do we want to send default as the default header? I'd prefer to send nothing if it is generic, and then let people set something custom, if required. If Okta would prefer to always have a value, I'd prefer a term like undefined or generic to describe the type of device accessing the API as opposed to default which is the parameter state.

[jkowall]

1. Versioning for the user agent, I see in your demo, you it set to 1.0, I think setting the version to the active version of the plugin would be more useful.

I will let Okta answer that, but you might want to version the user agent based on changes the vendor made to the integration with Okta. That would include plugin version and maybe a vendor revision number they can set.

2. I still hopes that this will be accepted to New Input Plugin: logstash-input-okta_system_log elastic/logstash#10251, but haven't heard anything. Accordingly, I'm worried about making the UserAgent explicitly tied to any (including our) company name. Would a name like LogstashInputPlugin work as the header?

I think the idea would be for the integration vendor to set this, for example my company logzio would set this to our name so that Okta knows this is one of our customers using the integration. If they are using Elastic, they might set it to Elastic. This would be up to the user, of course, and some will not set it accordingly. This would help Okta track down issues which might be related to a vendor/

3. Do we want to send default as the default header? I'd prefer to send nothing if it is generic, and then let people set something custom, if required. If Okta would prefer to always have a value, I'd prefer a term like undefined or generic to describe the type of device accessing the API as opposed to default which is the parameter state.

I'll let @mbegan answer this one :)

[p-b--]

I will let Okta answer that, but you might want to version the user agent based on changes the vendor made to the integration with Okta. That would include plugin version and maybe a vendor revision number they can set.

That might over complicate things -- If the vendor would like to set up a version number, they can do so in their config, it's a free-form field so they can do what they like.

I think the idea would be for the integration vendor to set this, for example my company logzio would set this to our name so that Okta knows this is one of our customers using the integration. If they are using Elastic, they might set it to Elastic. This would be up to the user, of course, and some will not set it accordingly. This would help Okta track down issues which might be related to a vendor/

My comment was more addressed around the main header, and not the custom portion, so in my mind instead of SecurityRiskAdvisorsLSP/1.0 (logz.io) we would use LongstashInputPlugin/0.10 (logz.io). I prefer that since it doesn't create confusion with multiple company names.

@mbegan -- if you have any comments let me know, otherwise I'll make some changes to the plugin based on our discussion.

[mbegan]

For my part, as long as I can expect the LongstashInputPlugin/ to be consistent I am good with the proposal.

[p-b--]

Apologies -- I didn't see this last update. I'll throw something together to test shortly.