OIDC managed groups don't get proper permissions

Not sure it’s my configuration mistake or bug but I can’t get managed groups to get proper permissions.

Here’s my oidc auth and managed group config

resource "boundary_auth_method_oidc" "auth0" {
  name                 = "Auth0"
  description          = "OIDC auth method for Auth0"
  scope_id             = var.org_scope
  issuer               = var.issuer
  client_id            = var.client_id
  client_secret        = var.client_secret
  signing_algorithms   = ["RS256"]
  api_url_prefix       = var.addr
  is_primary_for_scope = true
  state                = "active-public"
  max_age              = 0
}

resource "boundary_managed_group" "admins" {
  name           = "Auth0"
  description    = "OIDC admin managed group for Auth0"
  auth_method_id = boundary_auth_method_oidc.auth0.id
  filter         = "\"admin\" in \"/userinfo/boundary_login/group\""
}

I can see that users that logged through oidc become members of the managed group


Here’s the boundary roles that I create with admin grant on organization and project scopes.

resource "boundary_role" "oidc_org_admin_role" {
  principal_ids = [boundary_managed_group.admins.id]
  grant_strings = ["id=*;type=*;actions=*"]
  scope_id      = var.org_scope
}

resource "boundary_role" "oidc_project_admin_role" {
  principal_ids = [boundary_managed_group.admins.id]
  grant_strings = ["id=*;type=*;actions=*"]
  scope_id      = boundary_scope.dev.id
}

Both roles are created and have managed group as principal

$ boundary roles read -id r_3F3ZzyeqYe  -addr="https://boundary-adress"

Role information:
  Created Time:        Sun, 04 Sep 2022 08:12:11 IDT
  Grant Scope ID:      o_aJizYHMHQc
  ID:                  r_3F3ZzyeqYe
  Updated Time:        Sun, 04 Sep 2022 08:20:53 IDT
  Version:             5

  Scope:
    ID:                o_aJizYHMHQc
    Name:              company_name
    Parent Scope ID:   global
    Type:              org

  Authorized Actions:
    no-op
    read
    update
    delete
    add-principals
    set-principals
    remove-principals
    add-grants
    set-grants
    remove-grants

  Principals:
    ID:             mgoidc_D1T8Aauvd9
      Type:         managed group
      Scope ID:     o_aJizYHMHQc

  Canonical Grants:
    id=*;type=*;actions=*


$ boundary roles read -id r_Zvx9AN5eGN  -addr="https://boundary-adress"

Role information:
  Created Time:        Sun, 04 Sep 2022 08:12:11 IDT
  Grant Scope ID:      p_SpLDKW7fBK
  ID:                  r_Zvx9AN5eGN
  Updated Time:        Sun, 04 Sep 2022 08:20:53 IDT
  Version:             5

  Scope:
    ID:                p_SpLDKW7fBK
    Name:              Dev
    Parent Scope ID:   o_aJizYHMHQc
    Type:              project

  Authorized Actions:
    no-op
    read
    update
    delete
    add-principals
    set-principals
    remove-principals
    add-grants
    set-grants
    remove-grants

  Principals:
    ID:             mgoidc_D1T8Aauvd9
      Type:         managed group
      Scope ID:     o_aJizYHMHQc

  Canonical Grants:
    id=*;type=*;actions=*

However when logged in as an OIDC user I cannot see expected admin permissions here’s a screenshot.

When I explicitly add the user principal to same role everything starts to work properly.

boundary roles read -id r_Zvx9AN5eGN -addr="https://boundary-adress"

Role information:
  Created Time:        Sun, 04 Sep 2022 08:12:11 IDT
  Grant Scope ID:      p_SpLDKW7fBK
  ID:                  r_Zvx9AN5eGN
  Updated Time:        Sun, 04 Sep 2022 08:52:49 IDT
  Version:             6

  Scope:
    ID:                p_SpLDKW7fBK
    Name:              Dev
    Parent Scope ID:   o_aJizYHMHQc
    Type:              project

  Authorized Actions:
    no-op
    read
    update
    delete
    add-principals
    set-principals
    remove-principals
    add-grants
    set-grants
    remove-grants

  Principals:
    ID:             mgoidc_D1T8Aauvd9
      Type:         managed group
      Scope ID:     o_aJizYHMHQc
    ID:             u_YqY7ABrOJy
      Type:         user
      Scope ID:     o_aJizYHMHQc

  Canonical Grants:
    id=*;type=*;actions=*

Here’s a screenshot

Can you issue a read on the account so that I can see what your claims look like? Thanks!

boundary accounts read -id acctoidc_dU2B9WVuro  -addr="https://boundary-address"

Account information:
  Auth Method ID:      amoidc_3rFImsHF9C
  Created Time:        Fri, 02 Sep 2022 17:45:19 IDT
  ID:                  acctoidc_dU2B9WVuro
  Type:                oidc
  Updated Time:        Sun, 04 Sep 2022 21:23:50 IDT
  Version:             10

  Scope:
    ID:                o_aJizYHMHQc
    Name:              company_name
    Parent Scope ID:   global
    Type:              org

  Authorized Actions:
    no-op
    read
    update
    delete

  Attributes:
    issuer:            https://dev-sr5fb36x.us.auth0.com/
    subject:           auth0|63118ccec2a71232bc8c5b5a
    token_claims:
    {
    "aud": "d4AEvvnY03U0WDyNiy8LThqSKxgQtntH",
    "boundary_login/group": "admin",
    "exp": 1662351829,
    "iat": 1662315829,
    "iss": "https://dev-sr5fb36x.us.auth0.com/",
    "nonce": "vXXBByAq5YaJHITsMS9O",
    "sid": "epb0ThE8pbpYcnurk7K0_h0qe6vHITBh",
    "sub": "auth0|63118ccec2a71232bc8c5b5a"
    }
    userinfo_claims:
    {
    "boundary_login/group": "admin",
    "sub": "auth0|63118ccec2a71232bc8c5b5a"
    }

Note that in syntax in the filters is for arrays. I don’t remember offhand if it will work for scalar values. That said, I see another issue with your filter: in JSON Pointer slashes denote reference tokens. So between the in syntax and the format of your data the filter you’re using expects a structure like this:

"boundary_login": {
  "group": ["admin"]
}

You need to escape the slash via the RFC-denoted escape, which is ~1. So I believe the filter you actually want is – escaped properly for TF – "/userinfo/boundary_login~1group" == "admin"

Let me know how that goes!

1 Like

Thank you Jeff,

I’ve changed the filter from this:

filter         = "\"admin\" in \"/userinfo/boundary_login/group\""

to this:

  filter = "\"/userinfo/boundary_login~1group\" == \"admin\""

And now grants on the managed groups works as expected.

What I don’t understand however is why despite my filter being incorrect I was able to see accounts ( that matched the user principal ) as members the OIDC managed group . You can see a screenshot of it my original post.

And another question if being a member of oidc managed group is not a good enough indication do I have any other indicator except just going straight for the filters ? Maybe some logging hints or attributes in resources?

I’m also not sure. I’ve gone through the code and the only time managed group memberships are evaluated is at login time. I don’t really have an answer at this time as to why you’d see it in the list when the filter was incorrect.