feat: add identity client passthrough and tests

[nborges-aws]

Description of changes:

• Add __getattr__ passthrough with accept_snake_case_kwargs to IdentityClient
• Control plane allowlisted methods (11):
  • OAuth2 credential provider CRUD: create_oauth2_credential_provider, get_oauth2_credential_provider, list_oauth2_credential_providers, update_oauth2_credential_provider, delete_oauth2_credential_provider
  • API key credential provider CRUD: create_api_key_credential_provider, get_api_key_credential_provider, list_api_key_credential_providers, delete_api_key_credential_provider
  • Workload identity: get_workload_identity, update_workload_identity
• Data plane allowlisted methods (5):
  • get_resource_oauth2_token, get_resource_api_key, get_workload_access_token, get_workload_access_token_for_jwt, get_workload_access_token_for_user_id
• Remove 4 explicit methods with no additional logic, now covered by passthrough: create_oauth2_credential_provider, create_api_key_credential_provider, update_workload_identity, get_workload_identity
• Retain explicit methods that have additional logic: get_workload_access_token, create_workload_identity, complete_resource_token_auth, get_token, get_api_key

Note: create_oauth2_credential_provider_and_wait and delete_oauth2_credential_provider_and_wait were originally part of this change, but were removed. Though the service model defines a status field on the GetOauth2CredentialProvider response, integ tests revealed that the API was not returning any status field. The provider became available synchronously after creation. Polling methods were timing out waiting for a status that never appears, even when provider was created successfully. Thus the *_and_wait methods were dead code.

Test plan:

• Unit tests (24 total):
  • Existing tests updated to use getattr passthrough calling convention (kwargs instead of positional dict)
  • OAuth2/API key creation, workload identity CRUD, token flows, auth completion, token polling
• Integration tests (9 total):
  • Passthrough: list OAuth2 providers, list API key providers, list with snake_case kwargs
  • Error handling: get nonexistent OAuth2 provider, get nonexistent API key provider
  • OAuth2 CRUD lifecycle: create → get → delete

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[github-actions]

⚠️ Breaking Change Warning

Found 4 potential breaking change(s) in this PR:

�[1msrc/bedrock_agentcore/services/identity.py�[0m:0: IdentityClient.create_oauth2_credential_provider: �[33mPublic object was removed�[39m
�[1msrc/bedrock_agentcore/services/identity.py�[0m:0: IdentityClient.create_api_key_credential_provider: �[33mPublic object was removed�[39m
�[1msrc/bedrock_agentcore/services/identity.py�[0m:0: IdentityClient.update_workload_identity: �[33mPublic object was removed�[39m
�[1msrc/bedrock_agentcore/services/identity.py�[0m:0: IdentityClient.get_workload_identity: �[33mPublic object was removed�[39m

---

Note: This is an automated static analysis check. Some flagged changes may be intentional.
Please confirm each item is expected and, if so, add a migration note to CHANGELOG.md.

[Hweinstock]

should we poll here?

[nborges-aws]

I'll change this to use wait_until_deleted utility

[Hweinstock]

now that we are proxying it through boto core, does the signature change at all? Would this be a breaking change for customers that already rely on this signature?

Same question for the other ones where we switched to passthrough.

[nborges-aws]

The signature and args do not change at all, but the methods go from accepting positional or keyword arguments to only keyword arguments. This is not a breaking change for any customer calling method(keyword="value"), but will break for those using method("value"). Boto3 does throw a clear error message when this happens:

TypeError: get_workload_identity() only accepts keyword arguments.

If we want to preserve full backwards compatibility, we would have to remove these methods from allowlist and add back explicit methods.

@jariy17 thoughts?

[Hweinstock]

this is defined as an explicit method and a passthrough. I think the passthrough takes precedence? If so, should we delete the old one?

[nborges-aws]

I think it's the other way around. Explicit methods are resolved first, and then it goes to passthrough.

But regardless, if I'm right the passthrough method is unreachable given we have an explicit method. Keeping it in the allowlist is pointless, and could confuse users. Will remove.