1

I'm developing a SPA that uses a Azure Function App for the API and Azure Active Directory for the auth. adal.access.token is set in local storage after the user logs in, but the claims are not set properly in the bound ClaimsPrincipal parameter, nor are they set within the HttpRequest parameter. The claims principal object looks the same whether or not the Authorization: Bearer ... header is set. How can I configure my Function App to use AAD and the ClaimsPrincipalbinding? I verified that the claims are set in the access token by using the token debugger at jwt.io.

public static MyFunction {
  [FunctionName("MyFunction")]
  public static async Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = "some-path")],
    ClaimsPrincipal principal
  ){
     // principal does not contain the claims, or any of the token info
  }
}

Then I send the request:

curl -X GET -H "Authorization: Bearer ..." http://localhost:7071/api/some-path

But the claims principle only has one claim, `http://schemas.microsoft.com/2017/07/functions/claims/authlevel: Admin`

UPDATE: It appears the principal variable is set as expected when invoked in Azure, but is not set when developing locally.

Eric
  • 11
  • 2

1 Answers1

0

i assume you created the app registration by using the function service app control panel by activating authentication with azure ad with express or something. doing so creates the app registration and puts the app function as the reply url, so if you run it locally on your development environment, and try to log in, it will never send the token to your local machine as its not a source url.

basically you have to go to the app registration in azure ad, go to authentication and add an additional reply / redirect url, to point to your localhost address of your app, whatever that is. http://localhost:youriisexpressport sorta thing. then it will work locally as well.

alphaz18
  • 2,610
  • 1
  • 5
  • 5
  • 2
    The issue isn't with logging in, it's with subsequent API calls. When developing locally, the claims principal is only being set with some default values... it only has one claim `authlevel: Admin`. When I push the same code to Azure and invoke the API function, the claims principal contains everything that's actually in the JWT string. – Eric May 15 '20 at 11:43
  • hope this helps: https://stackoverflow.com/questions/49390877/is-it-possible-to-debug-azure-functions-locally-with-azure-active-directory-auth/49402152#49402152 they seem to have a workaround here:, – alphaz18 May 15 '20 at 13:12
  • Have you tried looking at the sample, which does similar one - https://contos.io/working-with-identity-in-an-azure-function-1a981e10b900? – Dev May 17 '20 at 05:54