Auth with Azure AD
Hey :) Was hoping the .dotstatsuite community could help me out.
I am copying this issue from our internal Jira.
This task was originally meant for KeyCloak setup but we were really hesitant on launching a different auth solution other then Azure AD since DotStatSuite clearly states they support ALL identity providers.
.Stat Suite is based on openid-connect authentication. Any openid-connect compliant identity provider can be used.
The first thing we did was try to get Azure AD working with the following configuration in our Kubernetes environment as as well for testing using Docker Compose in our local environment. (Docker Compose file attached)
The following is the Authentication Configuration:
auth__enabled: ${AUTH_ENABLED}
auth__allowAnonymous: "false"
auth__authority: "https://login.microsoftonline.com/<tenant-id>/v2.0"
auth__authorizationUrl: "https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/authorize"
auth__clientId: "<client-id>"
auth__requireHttps: "false"
auth__validateIssuer: "false"
auth__showPii: "false"
auth__scopes__0: openid
auth__scopes__1: profile
auth__scopes__2: email
auth__claimsMapping__email: email
auth__claimsMapping__groups: groups
Ultimately as was mentioned by the Azure AD configuration doesn't work so we decided to trace down why since it is advertisted as working.
We ultimately traced down the problem and it is this commit where they moved from implicit flow to authorization code and the way that they wrote the code it will only ever work for keycloak.
We then confirmed and if we switch the auth-service backend to siscc/dotstatsuite-core-auth-management:9a653e82 (v4.0.0) everything works in the swagger UI.
We will likely file a P.R. upstream to fix this asking why the switch to authorizationCode, which in general is not for use in client-side browsers like this. At the very least we were hoping should have made the token URL a parameter. This line is likely the problem for us with Azue D:
{code:dotnet} TokenUrl = new Uri(_auth.AuthorizationUrl.Replace("openid-connect/auth", "openid-connect/token")), {code}
The last problem is the groups scope not working which we believe is due to the groups being too big as discussed in this issue
{quote} hasgroups Boolean If present, always true, denoting the user is in at least one group. Used in place of the groups claim for JWTs in implicit grant flows if the full groups claim would extend the URI fragment beyond the URL length limits (currently 6 or more groups). Indicates that the client should use the Microsoft Graph API to determine the user's groups (https://graph.microsoft.com/v1.0/users/{userID}/getMemberObjects).{quote}
The solution will likely be to use app roles which should remove the final blocker to using Azure AD for Auth.
The nice thing about App Roles is that it’s technically more controllable because you can map multiple AD groups to the same role without having to update your app.