sso-authentication errors when using allowed_groups

[namm2]

Describe the bug
So I'm having the following errors when use allowed_groups options:

{"action":"redeem","http_status":200,"level":"info","msg":"","proxy_host":"example.com","remote_address":"1.2.3.4","request_duration":0.21089899999999998,"request_method":"POST","request_uri":"/redeem","service":"sso-authenticator","time":"2019-07-19 09:59:34.7199","user":"[email protected]","user_agent":"sso_proxy/HEAD"}
{"circuit_change_from":2,"circuit_change_to":1,"level":"info","msg":"circuit breaker trigger","service":"sso-authenticator","time":"2019-07-19 09:59:34.7199"}
{"circuit_change_from":1,"circuit_change_to":2,"level":"info","msg":"circuit breaker trigger","service":"sso-authenticator","time":"2019-07-19 09:59:35.7199"}
{"backoff_duration":557015243,"backoff_reset":"2019-07-19T09:59:35.592592582Z","level":"info","msg":"circuit breaker backoff set","service":"sso-authenticator","time":"2019-07-19 09:59:35.7199"}
{"error":"googleapi: Error 403: Not Authorized to access this resource/api, forbidden","level":"error","msg":"error retrieving groups","service":"sso-authenticator","time":"2019-07-19 09:59:35.7199"}
{"action":"profile","http_status":500,"level":"info","msg":"","proxy_host":"","remote_address":"1.2.3.4","request_duration":381.978062,"request_method":"GET","request_uri":"/profile?client_id=SjA5ck0zdlMxNi9KZGJHVjFVWlZzUmtFSH123456789%3D\u0026email=user.email%40company.com\u0026groups=admins%40company.com","service":"sso-authenticator","time":"2019-07-19 09:59:35.7199","user":"","user_agent":"sso_proxy/HEAD"}

SSO configs:

  upstreams:
    - service: servicename
      default:
        from: example.com
        to: http://servicename.namespace.svc.cluster.local:8080
        options:
          allowed_groups:
            - [email protected]

And I already double checked the Oauth scopes mentioned in the docs, and [email protected] is the first level group (not the nested one). Any ideas?

To Reproduce

• Following the docs here: https://github.com/buzzfeed/sso/blob/master/docs/google_provider_setup.md
• Setting up SSO with allowed_groups block

Expected behavior
Only members of the group [email protected] has access to the backend.

Additional context
Additional SSO configs:

  provider:
    google:
      adminEmail: [email protected]

[svenmueller]

We are seeing the exact issue in our setup. We verified the configuration a couple of times (enabled organization-wide delegation etc.) but couldn't figure out why it's not working. The UI shows a screen with status 500 (logs are the same as in the issue description).

Any idea how to proceed with this issue (we tried setting log level to trace no further log messages are created, see #126).

[Jusshersmith]

Hi @namm2 (and @svenmueller!).

Thanks for sending this through, and apologies for not getting back to you yet. I'll be taking some time next week to properly work through this and get back to you.

Thank you both for your patience!

[Jusshersmith]

Hi @namm2,

Would you mind confirming that the email address set in the PROVIDER_*_GOOGLE_IMPERSONATE (that is going by SSO v2.0.0 config vars, I believe it was GOOGLE_ADMIN_EMAIL before that) environment variable is an administrator account for the org, and what roles & oauth privileges it has assigned please?

I believe you can find that information through the following steps:
log into the admin console -> search for user -> look under 'admin roles and privileges' -> click 'roles'

[svenmueller]

@Jusshersmith Thx for coming back to us. I just check the user and in our case the used GMail account has no roles or specific permissions applied. If that is required, which exact role/permission is expected?

[jphines]

@svenmueller I'm sorry for the trouble. This is a quirk of the Google Admin API and a bit tricky to get right / explain.

For some subsets of the Google Admin API (including the ones we require), Google requires that service accounts act on behalf of another user. https://stackoverflow.com/questions/48585700/is-it-possible-to-call-apis-from-service-account-without-acting-on-behalf-of-a-u/48601364#48601364

The account you are impersonating must have Admin API Access. See https://support.google.com/a/answer/60757. You can either create or choose an existing administrative email address to supply for the impersonate field for sso.

As far as I know, this is the only way to enable this access and its akin to jumping through 🔥 hoops.

[rlabrecque]

I spent a long time fighting various issues like this today; after getting the account permissions correct we ran into:

We're using the minddoc helm chart and the primary issue was the .Values.proxy.defaultAllowedEmailDomains field:

values.yaml:

proxy:
  # If you are using_allowed groups in upstreams, DEFAULT_ALLOWED_EMAIL_DOMAINS needs to be an empty string
  # this is explained in this pr https://github.com/buzzfeed/sso/pull/280#issuecomment-584088825
  # to get an empty value, set the string below to -, as per this issue https://github.com/helm/helm/issues/2600#issuecomment-310108850
  # otherwise populate it with your default allowed email domains
  defaultAllowedEmailDomains: "-"

upstreams:
  - service: 'redacted'
    default:
      from: 'redacted.redacted.com'
      to: 'http://redacted.prod.svc.cluster.local'
      options:
        allowed_groups:
          - [email protected]

[namm2]

@rlabrecque that option was introduced since #253 I believe it fixed this issue