App group lifecycle plugin #351
Conversation
0b8c460 to
23f866d
Compare
…rving current DB session commit groupings.
…ith hook invocations for plugin-specific config validation.
…fecycle plugins to power frontend components writing config and reading config and status for plugins.
… dev to reduce log noise.
… to install the Datadog metrics reporter and app group lifecycle audit logger plugins, and polish descriptions.
b364a87 to
00a0b8b
Compare
| raise ValueError(f"Duplicate plugin ID detected: {plugin.id}") | ||
| if plugin.display_name in seen_display_names: | ||
| raise ValueError(f"Duplicate plugin display name detected: {plugin.display_name}") | ||
| if plugin.description in seen_descriptions: |
There was a problem hiding this comment.
We're probably not going to see collisions of plugin descriptions unless someone copy-pastas one as a template, we probably okay not requiring uniqueness, but we can leave this as this is minor either way.
There was a problem hiding this comment.
- ModifyGroupUsers needs to handle membership changes on roles with associated app groups with an app group plugin installed
- ModifyRoleGroup needs to handle app group membership changes when a role is added or removed from an app group with an app group plugin installed
- ModifyGroupType needs to handle the case where an app group with a plugin installed is no longer an app group
- Audit logging should be added for plugin charges (config to an app or group, etc)
- Missing type definitions for
PluginConfigProperties,PluginStatusProperties, andPluginConfigPropertyneed to exist in apiComponents.ts (does the the client compile/build?)
| Dictionary mapping property names to property schemas | ||
| """ | ||
| # Verify the plugin is registered | ||
| plugins = [plugin.id for plugin in get_app_group_lifecycle_plugins()] |
There was a problem hiding this comment.
It's unlikely we'll have a significant number of plugins for this to matter, but this could probably be made efficient by storing the plugins as a dictionary indexed by id. get_app_group_lifecycle_plugins() would return plugins.values() and get_app_group_lifecycle_plugin(plugin_id: str) would return plugin[plugin_id]
… binary membership status changes (vs redundant access being added/removed).
Good catch! Added the missing logic for these and validated via new unit tests and E2E testing in local dev.
Whoops, IDK how these imports got messed up; probably in some interactive rebasing to clean up commit history.
I don't think that there's any handling needed here, as the group will no longer have an associated plugin ID and so hooks won't be called. |
somethingnew2-0
left a comment
There was a problem hiding this comment.
Thanks for the fixes! Just one comment on including new plugin_data on the audit log schema.
Summary of Changes
This PR introduces a new type of Access plugin called an "app group lifecycle plugin." Such plugins support managing downstream applications based on Access app group existence and membership. This facilitates a light SCIM implementation where downstream apps' support for Okta SCIM is lacking.
Our team has already envisioned three use cases for such a plugin:
UI Screenshots
Create app
Update app
Create app group
View app
Update app group
View app group
Reviewing
There's a lot of code here (thanks, Claude!), so I strongly recommend going commit-by-commit for logically-grouped changes. This is also a substantial enough feature that I'd encourage reviewers to try it themselves in local dev.
Testing
Unit Tests
All of the plugin spec's public functions have unit tests. Run them via:
tox -e test -- tests/test_app_group_lifecycle_plugin.pyE2E Testing
I've installed the example plugin and run the app locally to play around with the UX pretty extensively.