Jamf config for PluginSpecV1#26374
Conversation
flyinghermit
changed the title
| // PluginTypeOkta is the Okta plugin | ||
| PluginTypeOkta = "okta" | ||
| // PluginTypeMDM represents MDM plugin type collectively | ||
| PluginTypeMDM = "mdm" |
There was a problem hiding this comment.
This will be used in the Web API to differentiate MDM plugins vs Access plugins.
There was a problem hiding this comment.
Plugin can only have one type, so would Jamf have type mdm or jamf?
What are the expected uses of grouping different plugins as mdm? We can probably tell if the plugin is MDM "statically", e.g.
func (p *PluginV1) IsMDM() bool {
return p.GetType() == PluginTypeJamf || p.GetType() == PluginTypeSomeOtherMDM
}We do not group Slack/Discord/MSTeams as some PluginTypeAccess. Well, one could argue that's because only Slack exists from that category for now 😅
There was a problem hiding this comment.
We can also have a label for MDM plugins, if that helps us query/filter them somehow.
There was a problem hiding this comment.
sorry I missed the input box here and replied below in comment thread below.
To add more, I think it will be way easy and less compute hungry to just compare string rather than the example above. I think metadata label should work as well but should those label's be used for customer specific labeling instead of internal system level labeling? I don't have strong opinion on that but just think PluginTypeMDM will be simple option to group mdm types.
There was a problem hiding this comment.
SubKind sounds okay, I guess.
Type is a bit different - it is specific to Plugin, is not a field (instead derived from the Settings variant), and is already used for concrete types (Slack, OpenAI, etc.), rather than categories (access, MDM, etc.)
I would suggest leaving PluginTypeJamf, and have MDM as the SubKind. Perhaps introduce PluginKindAccessRequest or similar, and PluginKindMDM.
There was a problem hiding this comment.
Hmm, that sounds more reasonable. I'll add a new PluginSubKind types and remove MDM type from here.
| } | ||
| } | ||
|
|
||
| // PluginIdSecretCredential can be OAuth2-like client_id and client_secret or username and password. |
There was a problem hiding this comment.
In what cases will we accept OAuth2 client_id and client_secret from the user? Will this be how we handle Mattermost etc., where we can not have one predefined Client ID, owned by us?
There was a problem hiding this comment.
Self hosted Mattermost was in mind when I wrote that comment. But basically I tried to make this as generic as possible where we can recevice clientID:clientSecet, apiKey:apiToken, uname:pass.
| // PluginTypeOkta is the Okta plugin | ||
| PluginTypeOkta = "okta" | ||
| // PluginTypeMDM represents MDM plugin type collectively | ||
| PluginTypeMDM = "mdm" |
There was a problem hiding this comment.
Plugin can only have one type, so would Jamf have type mdm or jamf?
What are the expected uses of grouping different plugins as mdm? We can probably tell if the plugin is MDM "statically", e.g.
func (p *PluginV1) IsMDM() bool {
return p.GetType() == PluginTypeJamf || p.GetType() == PluginTypeSomeOtherMDM
}We do not group Slack/Discord/MSTeams as some PluginTypeAccess. Well, one could argue that's because only Slack exists from that category for now 😅
There's possibly two place where MDM type will be useful:
|
* jamf specefic config added to proto and plugin type * JamfSpecV1 added to PluginJamfSetting * remove PluginCredentialType type * update plugin jamf spec name * removed mdm from plugin type and added a new PluginSubkind
* jamf specefic config added to proto and plugin type * JamfSpecV1 added to PluginJamfSetting * remove PluginCredentialType type * update plugin jamf spec name * removed mdm from plugin type and added a new PluginSubkind Co-authored-by: Sakshyam Shah <sshah@goteleport.com>
4 participants
PluginJamfSettingsadded toPluginSpecV1.PluginV1.GetType()to handle jamf type.