Using Azure AD OpenID Connect (OIDC) for Authentication

[tribble3891]

Hey @seizste

I am still struggling with that at the moment still, no combination seems to have worked

There is someone else in the sensu-go issues list stating they are having issues also https://github.com/sensu/sensu-go/issues/3058 but seem stuck because maybe they are not passing the token properly through. When I tried some of that configuration I never even got to login at all

@jspaleta - apologies to ping directly! Do you know if there are any known issues with sensu using AzureAD as a auth provider at the moment or can see if we are doing anything obviously wrong?

[jspaleta]

Hey,

I’m not aware of an issue no.
I’m personally most familiar with interacting with Azure using the addon ldap services and no oidc.

But if you are able to login into the dashboard using the user defined in AzureAD, instead of a sensu locally defined user, then this is probably just a configuration issue with how sensu RBAC role bindings are configured

I would need to see a redacted version of the authentication resource to be sure but my gut tells me this is a misunderstanding on how the groups_prefix and users_prefix settings in the authentication providers resource interact with RBAC.

Assuming for example you have using something like

groups_prefix: 'oidc:'

in your Azure oidc auth provider configuration… then the your ClusterRoleBindings and RoleBindings resources would need to have rules with group names prefix with ‘oidc:’

Following that assumption about your group_prefix setting I would expect to see something like this:

{
  "type": "ClusterRoleBinding",
  "api_version": "core/v2",
  "metadata": {
    "name": "gpcms-cluster-admins"
  },
  "spec": {
    "role_ref": {
      "name": "cluster-admin",
      "type": "ClusterRole"
    },
    "subjects": [
      {
        "name": "oidc:aad:b2b1bfee-2d5d-55e7-9537-e5b30f1c3456",
        "type": "Group"
      },
      {
        "name": "oidc:b2b1bfee-2d5d-55e7-9537-e5b30f1c3456",
        "type": "Group"
      }
    ]
  }
}

[tribble3891]

Hey

Thanks for taking the time to respond. From a rol-binding perspective I am using the following (tried using both methods):

---
type: RoleBinding
api_version: core/v2
metadata:
  created_by: admin
  labels:
    sensu.io/managed_by: sensuctl
  name: role_binding_administrators
  namespace: default
spec:
  role_ref:
    name: role_administrators
    type: Role
  subjects:
  - name: oidc:608dXXXXXXXXXXXXXXb133d322
    type: Group
  - name: 608dXXXXXXXXXXXXXXb133d322
    type: Group

My role then looks like:

type: Role
api_version: core/v2
metadata:
  created_by: admin
  labels:
    sensu.io/managed_by: sensuctl
  name: role_administrators
  namespace: default
spec:
  rules:
  - resource_names: null
    resources:
    - assets
    - checks
    - entities
    - events
    - filters
    - handlers
    - hooks
    - mutators
    - rolebindings
    - roles
    - silenced
    verbs:
    - get
    - list
    - create
    - update
    - delete

From an authentication provider:

type: OIDC
api_version: authentication/v2
metadata:
  created_by: admin
  labels:
    sensu.io/managed_by: sensuctl
  name: AzureAD
spec:
  additional_scopes:
  - email
  - upn
  - groups
  - username
  client_id: REDACTED
  client_secret: REDACTED
  groups_claim: groups
  groups_prefix: 'oidc:'
  redirect_uri: https://REDACTED/api/enterprise/authentication/v2/oidc/callback
  server: https://sts.windows.net/REDACTED/
  username_claim: upn
  username_prefix: 'oidc:'

That looks too potentially match what I think i should have - most likely have misunderstood how it applies, I can see my group in the GUI with the UPN for the accound:

[jspaleta]

unless I’m forgetting something else, I expect this to match

- name: oidc:608dXXXXXXXXXXXXXXb133d322
  type: Group

[tribble3891]

Hey

Those do actually match when not censored out.

When i checked out groups_claims should be an array of strings (https://docs.sensu.io/sensu-go/latest/installation/auth/#oidc-specification). When i add multiple groups to be passed through i can see its an array and it looks to pre-popuate all of them

I just assumed that Sensu put it in the format oidc:[“GROUP 1”, “Group2”] to make it more readable. Wondering if the way azure is passing the token through is not properly formatted for Sensu to parse it ?

[jspaleta]

I think perhaps we are talking past each other… or I’m just tired. I’m not sure why you are referring to the groups claim when I’m referring to the groups_prefix
I dont know what you mean by censored out. I feel like I’m missing something important about your config.

The groups_claim is part of the oidc request spec.

The groups_prefix and users_prefix are optional strings that sensu adds to the user and auth provider group and user for sensu specifc rbac.

Sorry I haven’t walked through an azure oidc myself yet. But to be clear if you have groups_prefix set your gonna have to make sure your sensu role subject has that prefix at the start… that’s the point I’m trying to get across.

[jspaleta]

Okay,
I really wish there was an easy way to reconstruct the exact oauth call being done behind the scenes so you could poke at the Azure oauth response with curl. But i would encourage you to try that and look at the json response so you can get a handle on what Azure is doing with regard to populating the groups claim.

Reading up on the Azure documentation for their OIDC implementation backed by AD, it looks like you have some tunables as to what AD attributes get mapped into the array value of the groups_claim associated with the outh2 application you setup in Azure to use with Sensu. It could be that you may have to change some settings to get the array of strings you expect from AD.
I can’t tell you what you expect however, because I don’t have access to your AD which makes it very difficult to walk you through it.
Here’s what I think the best Azure reference doc for the tunable is

Configure group claims for applications with Azure Active Directory

From the documentation there are several ways to populate the groups_claim. You are probably just not using the correct option, probably just getting the application level group, not the groups associated with the user.

It would definitely be easier for you to be able to poke at this with some curl commands until you got the Azure settings right. I think its gonna be pretty obvious once you get Azure configured correctly. You’re definitely getting the basics right, Azure is providing a json response with a “groups” attribute… its just not populated with what you expect it sounds like.

I hope this helps.

[tribble3891]

Hey

Apologies on the above I meant to say group_prefix and not group_claim.

I will have a poke around to see if i can get what is being passed Sensu in the JWT.

thanks

[tribble3891]

Hey,

Did some digging and found the JWT that is being used. The JWT is below:

{
  "exp": 1592030274,
  "jti": "ec02ea423c21bd431058a9dc929056a2",
  "sub": "oidc:username@domain.com",
  "groups": [
    "oidc:[\"70aed41c-93ef-4088-9fab-196d5d978c9e\",\"8a5d117e-bbbf-4706-ac17-81136e33d7bf\",\"608d8baf-b7d4-4fe1-a5d7-aac3b133d322\"]"
  ],
  "provider": {
    "provider_id": "AzureAD",
    "provider_type": "oidc",
    "user_id": "6JNSeRcDSv1fJOeWTf0L4uMrR4s3liNuyC4lP8cW_kY"
  },
  "api_key": false
}

I pass the group claims properly as groups_claim expects a array of strings, When I look inside sensu for the groups that are seen is correct, this also matches with the AzureAD groups my user has:

Groups my user is in AzureAD which show up properly (limited it to show just the sensu ones for brevity but those other groups above I am a member of):

PS /home/admin> Get-AzureADGroup | ? {$_.DisplayName -like "*Sensu*"}

ObjectId                             DisplayName  Description
--------                             -----------  -----------
1fd669b5-2b1a-46f7-bb36-48591caa9131 Sensu Viewer
608d8baf-b7d4-4fe1-a5d7-aac3b133d322 Sensu Admins

I pass my group claims using the below in my Azure AD application token configuration step (I have tried every configuration incl mapping them as roles):

I have a role mapping which seems to be set properly:

Type: Role
api_version: core/v2
metadata:
  created_by: admin
  labels:
    sensu.io/managed_by: sensuctl
  name: role_administrators
  namespace: default
spec:
  rules:
  - resource_names: null
    resources:
    - assets
    - checks
    - entities
    - events
    - filters
    - handlers
    - hooks
    - mutators
    - rolebindings
    - roles
    - silenced
    verbs:
    - get
    - list
    - create
    - update
    - delete

There is a corresponding role-binding which maps my Azure AD GUID (with oidc: in front since i have groups_prefix set):

type: RoleBinding
api_version: core/v2
metadata:
  created_by: admin
  labels:
    sensu.io/managed_by: sensuctl
  name: role_binding_administrators
  namespace: default
spec:
  role_ref:
    name: role_administrators
    type: Role
  subjects:
  - name: oidc:608d8baf-b7d4-4fe1-a5d7-aac3b133d322
    type: Group

That should properly map the GUID from Azure. AD with the role which grants access but I still see nothing and get the error in the logs (I know the role binding is also correct and does grant information as i created a local user and added a subject of name: test and type: User and i could see everything):

{"component":"apid.graphql","error":"request unauthorized","level":"warning","msg":"couldn't access resource","time":"2020-06-13T18:19:48+10:00"}

Appreciate your help/feedback so far below is also the oidc config

type: OIDC
api_version: authentication/v2
metadata:
  created_by: admin
  labels:
    sensu.io/managed_by: sensuctl
  name: AzureAD
spec:
  additional_scopes:
  - email
  - upn
  - profile
  - groups
  client_id: my_id_here
  client_secret: my_secret_here
  groups_claim: groups
  groups_prefix: 'oidc:'
  redirect_uri: https://sensu.my_url.com/api/enterprise/authentication/v2/oidc/callback
  server: https://sts.windows.net/TENANT/
  username_claim: upn
  username_prefix: 'oidc:'

I must have something configured wrong somewhere i guess since I keep getting prompted constantly to reconsent still for sensu app to have access to information in my tenant.

[jspaleta]

Hmm…
so yeah according to the JWT info this sure looks right to me and matches how I expect the rule.

“608d8baf-b7d4-4fe1-a5d7-aac3b133d322”

Maybe there’s a bug here. Can you remove the oidc group prefix in your auth resource? Just set it to “”
And then redo your RoleBinding to remove the ‘oidc:’ prefix in the subjects.

[jspaleta]

Actually…
that JWT token might not be what I expect… why does the groups claim have an oidc: prefix in it?
I think its suppose to just be an array
I’m expecting to see:

  "groups": 
    ["70aed41c-93ef-4088-9fab-196d5d978c9e","8a5d117e-bbbf-4706-ac17-81136e33d7bf","608d8baf-b7d4-4fe1-a5d7-aac3b133d322"]

It looks like Azure is doing is treating ‘groups’ as a keyvalue hash and putting the expected string array inside of the oidc key in the hash. So I think that’s the problem.

So I guess we need to figure out how to configure for that in Sensu’s auth config. maybe the groups_claim value in the Sensu resource needs to be ‘groups.oidc’ instead of ‘groups’

[jspaleta]

@tribble3891
Ugh… i think Azure has broken the groups_claim array of strings expectation of OIDC in a subtle way
it looks like Azure isnt given us a clean array of strings.
technically its given us an array with a single string in it starting with oidc:[ and ending with ]
its like Azure is trying to wrap an array in an array, which it should be using a json hash.
Azure is doing this

  "groups": [
    "oidc:[\"70aed41c-93ef-4088-9fab-196d5d978c9e\",\"8a5d117e-bbbf-4706-ac17-81136e33d7bf\",\"608d8baf-b7d4-4fe1-a5d7-aac3b133d322\"]"
  ],

I would expect it to do this instead:

  "groups": ["70aed41c-93ef-4088-9fab-196d5d978c9e","8a5d117e-bbbf-4706-ac17-81136e33d7bf","608d8baf-b7d4-4fe1-a5d7-aac3b133d322"],

I’m not sure what to do here, what Azure is putting out right now for the groups attribute seems to break the groups_claim expectation.

[jspaleta]

@tribble3891
Maybe there’s a way to get Azure to change how its populating the groups JSON attribute via some tunable? End of the day OIDC spec seems to require whatever json attribute being used for the groups_claim to be an array of strings, each string matching the name of a group.

What Azure is passing right now is technically an array with one very long string in it, which is definitely wrong-ish. It sure feels like Azure is breaking the spec here.

[tribble3891]

Hey

So i removed the groups_prefix and ran it and i see the below as the JWT:

{
  "exp": 1592295583,
  "jti": "e1425f1bdc04fcbf44623sce4ffa4d95",
  "sub": "oidc:username@domain.com",
  "groups": [
    "[\"70aed41c-93ef-4088-9fab-196d5d978c9e\",\"8a5d117e-bbbf-4706-ac17-81136e33d7bf\",\"608d8baf-b7d4-4fe1-a5d7-aac3b133d322\"]"
  ],
  "provider": {
    "provider_id": "AzureAD",
    "provider_type": "oidc",
    "user_id": "6JNSeREDSv1fJODWTf0L4uMrR4s3liNuyC4lP8WW_kY"
  },
  "api_key": false
}

that then showed the following in Sensu with no permissions being granted

It definitely seems to be passing it incorrectly - i can’t see any tunables to change that, what i thought about doing was just passing a seperate attribute and using that as the group_claim but i couldn’t get it in the right format.

All i can see in the application manifest is to set: “groupMembershipClaims”: “SecurityGroup” unfortunately but I may be missing something (its late in AU at the moment)

[tribble3891]

Also when i try to use groups.oidc it can’t find the claim

{"message":"GroupsClaim not found","code":0}

[jspaleta]

Okay I think our friends at HashiCorp have documented the magic.Specifically there is discussion about the scope called “https://graph.microsoft.com/.default”

This maybe the missing magic that Azure requires to set the groups_claim correctly for OIDC.

Take a look at:

OIDC Provider Setup - Auth Methods | Vault by Hashicorp

Azure Ref:

Get access without a user - Microsoft Graph

[jspaleta]

no the groups.oidc thing was a red herring i added to the discussion.

The groups_claim value should be top level “groups” attribute in the JWT. We just have to find how to have Azure generated to expected array of strings as the value.

For an example of what the expected in the “groups” attribute of the decuded token take a look at this okta documentation:
https://developer.okta.com/docs/guides/customize-tokens-returned-from-okta/add-groups-claim-org-as/#request-an-id-token-that-contains-the-groups-claim

The okta example shows the token request and the expected decoded JWT with a the “groups” attribute holding an array of strings.

[tribble3891]

Yeah thats good to reference - will see if i can poke around a bit more to see if its possible to get it to return in the format is expecting without changes required in someones implementation.

Was trying to capture the oidc flow using fiddler earlier to see if i can track down where the extra pieces are coming from. Wasn’t able to find anything that allowed me to pinpoint Azure or Sensu yet (in case it was adding it on accidentally) but will keep digging.

RW

[jspaleta]

thanks for sticking with it!

I’m not sure how much I can help without taking the plunge into Azure myself.

I’m going to try to write some basic OIDC troubleshooting instructions using curl and cmdline tools to decode the JWT so it can be inspected with jq. This sort of manual troubleshooting might help operators who are having trouble configuring OIDC service providers. I always find that if I manually do the steps involved in an API interaction, I have a better time tracking down the failures and more importantly helps me file useful bug reports.

[tribble3891]

So having a dig around the config I still came up empty unfortunately but having a look since I am using https://sts.windows.net/tenant_id/ i am using OIDC v1 tokens on AzureAD. Having a look through some of the AzureAD issues on the hashicorp/vault i was able to find in #6494 which has the comment below:

I think we’ve finally gotten to the bottom of what’s causing this. When logging in via OIDC, the ID token is parsed, and then any claims found at the /userinfo endpoint are merged in. When using the sts endpoint the, groups list in the ID token is fine, but the same claim also exists in the /userinfo response as the stringified list: "groups":["[\"9e58c006-42ba-4406-9b13-f6132b0b29ab\",\"352b6bbe-9f59-4a65-9a7e-2f6cd2f26494\",\"45dd570d-2706-4d0a-bea7-b09fb4ad5691\"]"] . That value is replacing the good groups claim, which is why we’re see this issue only in the OIDC+ //sts... case

This seems to be similar to what I am doing and they seem to suggest moving to OIDC v2 instead which would target the following end point I believe (which is what other people seem to have tried previously):

https://login.microsoftonline.com/tenant_id/v2.0

This though when you look at the openid spec at:

https://login.microsoftonline.com/tenant_id/v2.0/.well-known/openid-configuration

This essentially gives:

{"token_endpoint":"https://login.microsoftonline.com/tenant_id/oauth2/v2.0/token","token_endpoint_auth_methods_supported":["client_secret_post","private_key_jwt","client_secret_basic"],"jwks_uri":"https://login.microsoftonline.com/tenant_id/discovery/v2.0/keys","response_modes_supported":["query","fragment","form_post"],"subject_types_supported":["pairwise"],"id_token_signing_alg_values_supported":["RS256"],"response_types_supported":["code","id_token","code id_token","id_token token"],"scopes_supported":["openid","profile","email","offline_access"],"issuer":"https://login.microsoftonline.com/tenant_id/v2.0","request_uri_parameter_supported":false,"userinfo_endpoint":"https://graph.microsoft.com/oidc/userinfo","authorization_endpoint":"https://login.microsoftonline.com/tenant_id/oauth2/v2.0/authorize","http_logout_supported":true,"frontchannel_logout_supported":true,"end_session_endpoint":"https://login.microsoftonline.com/tenant_id/oauth2/v2.0/logout","claims_supported":["sub","iss","cloud_instance_name","cloud_instance_host_name","cloud_graph_host_name","msgraph_host","aud","exp","iat","auth_time","acr","nonce","preferred_username","name","tid","ver","at_hash","c_hash","email"],"tenant_region_scope":"OC","cloud_instance_name":"microsoftonline.com","cloud_graph_host_name":"graph.windows.net","msgraph_host":"graph.microsoft.com","rbac_url":"https://pas.windows.net"}

the scopes_supported don’t support the groups scope that say OKTA supports (you can pass this as a token in the azure ad app but it makes no difference). If you try and request the following scopes with v2 configured:

type: OIDC
api_version: authentication/v2
metadata:
  created_by: admin
  labels:
    sensu.io/managed_by: sensuctl
  name: AzureAD
spec:
  additional_scopes:
  - email
  - profile
  - groups

This results in the following stating:

{"message": "GroupsClaim not found", "code": 0}

I can’t yet see a way around this but its interesting that they were able to get groups working when using v2 (which is essentially the link you provided further up in the chain) doesn’t seem to work given the scope does not exist:

Will have a crack at the permutations again just incase i have missed something, might also have a look a bit later at the consent part of the string as maybe it never gets the access and thus never gets passed…

RW