You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maka.apache.org by "liugddx (via GitHub)" <gi...@apache.org> on 2026/10/11 15:31:19 UTC
[I] design(providers): cloud-native auth for Azure AI Foundry (Entra ID) and Amazon Bedrock (SigV4 / IAM Identity Center) [maka]
liugddx opened a new issue, #6072:
URL: https://github.com/apache/maka/issues/6072
Follow-up from #6031. The API-key connections for Azure AI Foundry and Amazon Bedrock (#6032) deliberately cover only key-based access. This issue tracks the cloud-native authentication those entries do not provide, which #860 left out of the initial provider scope because it needs its own product design.
## Scope
- **Azure AI Foundry: Microsoft Entra ID.** Token acquisition and refresh, tenant/project selection, and how a Foundry project endpoint (rather than the `/openai/v1` or `/anthropic` resource endpoint) is configured.
- **Amazon Bedrock: AWS credentials.** SigV4 signing from the standard credential chain (profiles, environment, SSO cache), region selection, and IAM Identity Center sign-in.
- #3370 (keyuchen21) proposed IAM Identity Center for Bedrock under the `amazon-bedrock` provider id with an `aws_sso` credential kind. It was closed by the stale bot on 2026-10-07 for inactivity, not rejected. Reviving or rescoping it is the natural starting point.
- The API-key entry from #6032 uses a separate id, `amazon-bedrock-api-key`, so it does not collide with `amazon-bedrock`.
## Open design questions
1. One provider entry per cloud with a credential-kind choice, or separate entries per auth method, given that #6032 already ships an API-key entry?
2. Where credentials and refresh live: Desktop main, the Runtime Host, or the CLI. This includes how a remote (SSH) Runtime Host gets them.
3. What happens to an existing API-key connection if the same provider later gains a cloud-native credential kind (migration or coexistence)?
Refs #860, #3370, #6031, #6032.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] design(providers): cloud-native auth for Azure AI Foundry (Entra ID) and Amazon Bedrock (SigV4 / IAM Identity Center) [maka]
Posted by "keyuchen21 (via GitHub)" <gi...@apache.org>.
keyuchen21 commented on issue #6072:
URL: https://github.com/apache/maka/issues/6072#issuecomment-6253895025
@liugddx I will give it a try
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] design(providers): cloud-native auth for Azure AI Foundry (Entra ID) and Amazon Bedrock (SigV4 / IAM Identity Center) [maka]
Posted by "keyuchen21 (via GitHub)" <gi...@apache.org>.
keyuchen21 commented on issue #6072:
URL: https://github.com/apache/maka/issues/6072#issuecomment-6389038703
Trust-boundary diagram for the Bedrock design in #6277 (also embedded in §4 of the document):
- **Red** never leaves the Runtime Host: AWS role credentials stay in memory only (I11), and `configuration.credentials.export` rejects `cloud_identity_session` (I7).
- **Orange** is persisted on the Host only: the vault session (`0600`, atomic) and the one canonical `amazon-bedrock` catalog entry (I8).
- Only the user code, verification URL, account/role lists, and the selected identity cross the Host protocol. The user approves the code in any browser, so a remote (SSH) Host works the same way.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] design(providers): cloud-native auth for Azure AI Foundry (Entra ID) and Amazon Bedrock (SigV4 / IAM Identity Center) [maka]
Posted by "keyuchen21 (via GitHub)" <gi...@apache.org>.
keyuchen21 commented on issue #6072:
URL: https://github.com/apache/maka/issues/6072#issuecomment-6385392155
@liugddx @youlemei2022-web Opened the design as a draft: #6277.
It covers `amazon-bedrock` (IAM Identity Center → SigV4) only and keeps the shared decisions from this thread: separate entries per auth method, Host-owned device flow and refresh, and role credentials that never leave Host memory. The review findings from #3370 are written as invariants I1–I13, each with a required regression test. `azure-foundry-entra` is left as a follow-up that can reuse the same contract (§10).
Two questions for you (§11):
1. Should a Host credential-chain source (`~/.aws` on the Host machine) be in the first release, or later?
2. Do you prefer the generic `cloud_identity.*` operation family, or `bedrock.sso.*` as in #3370?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] design(providers): cloud-native auth for Azure AI Foundry (Entra ID) and Amazon Bedrock (SigV4 / IAM Identity Center) [maka]
Posted by "liugddx (via GitHub)" <gi...@apache.org>.
liugddx commented on issue #6072:
URL: https://github.com/apache/maka/issues/6072#issuecomment-6248522725
Here's a direction for the three open questions, based on how connections already work and on #3370.
**1. Separate entries per auth method, not one entry with a credential-kind choice.** Today each `providerType` has exactly one `authKind` (`providerDefaultsOf(...).authKind`, which `deriveProviderAuthContract` gates on), and #6032 already follows that rule with `amazon-bedrock-api-key`. Keeping it means:
- `amazon-bedrock` is IAM Identity Center / SigV4, as #3370 proposed.
- An Entra ID entry for Foundry gets its own id, for example `azure-foundry-entra`.
- No connection ever changes its auth kind in place.
**2. Credentials and refresh live in the Runtime Host.** OAuth subscriptions already work this way, and #3370 used the same pattern for Bedrock:
- The Host owns the device-authorization flow, the refresh tokens and the short-lived role credentials.
- Short-lived credentials stay in memory and are never persisted. Secrets never cross the protocol into renderer state.
- Desktop and the CLI only show the user code and verification URL.
Device authorization also answers the remote (SSH) Host case, because the user can complete sign-in on any machine. Reading `~/.aws` or environment credentials should be an explicit option on the Host side, reading the credential chain of the machine the Host runs on, never the client's.
**3. Coexistence, no migration.** Because the ids differ, an existing API-key connection keeps working unchanged next to a new cloud-native one. Users switch by adding the new connection. We can add a hint on the API-key entry later if we want to steer people.
**Suggested order:**
1. Bedrock first, by reviving #3370. It was closed by the stale bot, not rejected, and it already has live IAM Identity Center and `ConverseStream` evidence. It needs a rebase and a fresh epoch.
2. Then Foundry with Entra ID, which needs its own device-code flow and project-endpoint handling.
@keyuchen21, are you interested in picking #3370 back up? If not, it's open for anyone.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] design(providers): cloud-native auth for Azure AI Foundry (Entra ID) and Amazon Bedrock (SigV4 / IAM Identity Center) [maka]
Posted by "youlemei2022-web (via GitHub)" <gi...@apache.org>.
youlemei2022-web commented on issue #6072:
URL: https://github.com/apache/maka/issues/6072#issuecomment-6285520298
Thanks @keyuchen21 — go ahead. Keep it to the design first (separate `azure-foundry-entra` entry, Host-owned device flow + refresh, short-lived role credentials never leaving the Host), and open it as a draft so we can review the contract before implementation.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] design(providers): cloud-native auth for Azure AI Foundry (Entra ID) and Amazon Bedrock (SigV4 / IAM Identity Center) [maka]
Posted by "liugddx (via GitHub)" <gi...@apache.org>.
liugddx commented on issue #6072:
URL: https://github.com/apache/maka/issues/6072#issuecomment-6411965792
Thanks @keyuchen21 for the draft in #6277. Answers to the two questions in §11:
1. **Host credential chain:** not in the first release. Ship the IAM Identity Center device flow only. If added later, it must be an explicit per-connection choice and never a fallback for the device flow (I6).
2. **Operation family:** use the generic `cloud_identity.*` family, so `azure-foundry-entra` can reuse the same auth kind, vault kind and operation family later.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org