Closed lukepatrick closed 8 months ago
+1 Interested in this too
I was just thinking this myself, and here we are with an issue created 6 hours ago. #great-minds-think-alike
Hmm interesting take. I'm not entirely familiar with this flow, are there other plugins which already use this and forwarding the SSO token to the plugin itself?
@kissmikijr not that I've seen. Once the actual SSO is complete (i.e. through Azure AD or Github), a JWT is generated that's then passed to plugins. My understanding of this request is that the original token (from Azure or Github) be retained somewhere so that it can be used to call services which also use that auth mechanism.
I do see one problem with just passing the token along - the client ID of the original request will be Backstage, which will likely fail validation on any other services. I could see a setup like IdP relaying party trust working (something like this), but I imagine that would be provider-specific.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
@adamdabbracci makes a good suggestion.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
SSO to plugins - e.g. Pass along SSO token to ArgoCD rather than rely on a single auth token. If I have the BackStage UI and ArgoCD UI both authenticating to the same SSO (e.g. AD or GitHub), have Backstage send that token or trust/handshake to ArgoCD rather than require an argocd api token to be managed.
Feature Suggestion
In a large organization with a "multitenancy" model, I would like to not create more api tokens when all internal tools (backstage and ArgoCD) share the same AuthN providers.
Possible Implementation
Context