External Identity Group not persistent across multiple identity aliases

[stampycode]

Environment:

• Vault Version: 0.9.6

Expected Behaviour:

When I assign an External Identity Group to my user which is based off an LDAP group membership, I expect that once I login using LDAP, that group will be persisted until I login with LDAP again and I am no longer a member of that group.

When I login with GitHub with the same Vault identity, I expect my identity-entity to still be a member of the same External-Identity Group via LDAP.

Actual Behavior:

My Identity only has the permissions from the last successful login - if I login with LDAP and then GitHub, my identity has the permissions of the GitHub profile, not the LDAP profile.

When I login with my LDAP account, I see this in my identity entity:

  "direct_group_ids": [
    "19cdc4e9-ff69-xxxx-xxxx-xxxxxxxxxxxx" <- this is the group that has my admin policy
  ],

When I then login with my GitHub account, the group is removed from my identity entity:

  "direct_group_ids": [],

When I login with my LDAP account again, my identity has the admin policy.

When I login with my GitHub token again, my identity doesn't have the admin policy any more.

This has the side effect that if I login using my LDAP account, then all my previous VAULT_TOKENs issued by my GitHub logins all have the admin permissions granted by my LDAP login.

Steps to Reproduce:

• create 2 auth methods: ldap, github
• configure the LDAP endpoint to read group memberships from AD.
• create an LDAP group in Vault with the same name as an AD group the user is a member of.
• login to Vault via LDAP, confirm the user is automatically a member of the group in Vault.
• create an identity that combines GitHub and LDAP aliases for the same user
• login to Vault using GitHub token and LDAP account, prove the same identity ID is used.
• create an EXTERNAL Identity Group, that grants an "admin" policy
• create an Identity Group-Alias that corresponds to one of the LDAP groups the user is a member of
• login to Vault using LDAP, confirm the user has the identity-group assigned to their identity entity.
• login to Vault using GitHub token, confirm the user still has the identity-group assigned through LDAP.

Last step fails.

[jefferai]

This has the side effect that if I login using my LDAP account, then all my previous VAULT_TOKENs issued by my GitHub logins all have the admin permissions granted by my LDAP login.

Right, and the GitHub ones are lost. You should be getting the union of the two, because these policies aren't assigned to your tokens, they're assigned to your Identity via the groups. You as a person are being identified as the same entity in both cases, so the union of any permissions granted from either source become the full set of your permissions.

[jefferai]

Just to follow up on the above: although the policies attached to a token (directly) are immutable, the contents are evaluated at runtime. Changes to those policies affect all tokens with those policies attached on their next request. Similarly, when searching for policies via a token's attached identity, we evaluate the full set of policies at each request by looking at current group membership.

[stampycode]

Yeah I don't have any issue with the policies attached to the tokens, they work as expected.
The issue I have is that if I have a cron-script authenticating using my GitHub personal token, it authenticates to Vault, and in doing so, resets the permissions granted through LDAP to my current LDAP session.
It's not clear what the expected behaviour should be from the documentation, but I wouldn't expect this to be it.

[jefferai]

@stampycode The reset part is a bug. But you indicated that it was unexpected that after logging in with GitHub and then LDAP, the overall permissions would include policies granted to both. Just trying to get across that a union is the correct behavior (once this bug is fixed).

[jefferai]

@stampycode you can make your life easier by creating an internal group ("A") with the full union of policies, then making your ldap and github external groups subgroups of A. Your entity will then inherit the full set of policies regardless of where you log in, without you actually having to log into both in order to fully populate the set of policies. As a bonus, I think that will be a workaround for the bug you're seeing.

[stampycode]

@jefferai the issue with that is that the policy names issued to users are derived from LDAP group memberships, so these are populated by the LDAP auth module, not by an operator.
For the time being I have written an hourly cron to update the list of Vault group/policy memberships by pulling from LDAP, but I'm hopeful that fixing this issue will negate the need for this. 👍