Allow to specify custom subject for federated login

[tobiasdiez]

If you login using OIDC, the subject for the federated login is automatically generated based on the github context. However, sometimes it is convenient to provide a custom subject, e.g. if you want to support pushes to arbitrary branches (and not only exactly one branch).

[MoChilia]

Hi @tobiasdiez,
Allow me to clarify your inquiry:

• If you want to push to arbitrary branches, not only exactly one branch, then you can customize the subject of the federated credential to filter for a specific environment to have access to the whole repo.
• If you want to use OIDC in a workflow triggered by pull requests, then you can try filtering for pull_request events.
• Detailed instructions on how to customize the subject of the federated credential can be found in Configure a federated identity credential on an app.

The login action's role is to verify whether the current subject aligns with the subject configured for your federated credential. It's the subject of your federated credential that should be updated, not customizing the subject on the login action side. Feel free to correct me if I've misconstrued your request.

[tobiasdiez]

Thanks for your reply!

I would like to push to arbitrary branches in the repo, yes. However, we are already using environments (for a different purpose), so that's not really an option. Similarly, the pull_request event is also not helpful since the workflow should be triggered manually using workflow_dispatch. AWS allows to match the subject using wildcards but this doesn't seem to work with azure. Thus my idea was to specify a custom subject (e.g. myrepo/workflowname/workflow_dispatch) and register this subject in the azure portal.

[MoChilia]

I see. You want to grant the federated token to workflows across various branches within the repository. However, due to certain constraints, utilizing an environment is not feasible. Instead, you intend to utilize wildcards to define the subject, such as repo:MY_ORG/MY_REPO:*. However, as far as I know, Azure workload identity doesn't currently support this type of OIDC claim. I recommend you submit the feature request in https://github.com/Azure/azure-workload-identity to support wildcards for subjects in the scenario of GitHub actions.

[tobiasdiez]

okay, I've opened Azure/azure-workload-identity#1118 for this. However, I do think it should be possible to set a custom subject (for example in scenarios using workflow_dispatch which depending on the workflow can have quite a few different meanings)

[illrill]

I would also like a configuration option to specify which subject should be used when logging in.

In my scenario, I have a user-assigned managed identity configured with a branch federation subject repo:<org>/<repo>:ref:refs/heads/main. This is my workflow:

name: deployment
on:
  push:
    branches:
      - main
permissions:
  id-token: write
  contents: read
jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - uses: azure/login@v1
        with:
          client-id: ***
          subscription-id: ***
          tenant-id: ***

Login only works if the workflow job doesn't reference any Github environment. However, if the workflow job references a Github environment (for other reasons, e.g. variables and secrets), the login action automatically sets the subject repo:<org>/<repo>:environment:production (for which I don't have any federated credential), and it breaks.

Being able to configure the subject would allow me to use the branch federation and still reference an environment in my workflow job (for other reasons than authentication).

[MoChilia]

Hi @illrill,
Currently, azure/login only supports managed identities with federated credentials. Please note that managed identities without federation are still in development (#348). Therefore, if you haven't configured federated credentials for the managed identity, azure/login will fail to fetch the federated token.
However, you've brought out a good point. It is reasonable to use branch federation while referencing an environment. I will keep looking into what can be done in azure login action.

[YanaXu]

Hi @tobiasdiez, Azure Login Action relies on OIDC Token. It's the official method to get the OIDC Token provided by GitHub.
The way to "customize" a subject is extremely insecure. That means anyone can "fake" the subject and use it wherever they want.

[YanaXu]

I would also like a configuration option to specify which subject should be used when logging in.

In my scenario, I have a user-assigned managed identity configured with a branch federation subject repo:<org>/<repo>:ref:refs/heads/main. This is my workflow:

name: deployment
on:
  push:
    branches:
      - main
permissions:
  id-token: write
  contents: read
jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - uses: azure/login@v1
        with:
          client-id: ***
          subscription-id: ***
          tenant-id: ***

Login only works if the workflow job doesn't reference any Github environment. However, if the workflow job references a Github environment (for other reasons, e.g. variables and secrets), the login action automatically sets the subject repo:<org>/<repo>:environment:production (for which I don't have any federated credential), and it breaks.

Being able to configure the subject would allow me to use the branch federation and still reference an environment in my workflow job (for other reasons than authentication).

Hi @illrill, I think it's a valid requirement. However, it's beyond the scope of Azure Login Action.
Azure Login Action relies on GitHub generated OIDC Token.
Azure Login Action call GitHub to generate the OIDC token and send the token to Azure.
You can refer to one token example: Understanding the OIDC token.
You see, the OIDC token generated by GitHub contains not only sub, but also repository(org and repo) and ref(repo branch).
It depends on the talk between GitHub and Azure. Azure Login Action can't change the content of the OIDC token or fake it. Azure Login Action can't make Azure to read ref instead of sub.
Therefore, It's better to raise a question or feature request to GitHub or Azure.