Authentication Question

[ParagKale-SSE]

Hi,

I have a function app in my environment where the authentication is not set via portal. The HTTP triggered functions use function key for security and we are using the tool in injected more where durable function monitor functions are there along side the application functions in the same function app.

We don't want to set up authentication with in the portal which will cover all the functions under its scope.

Is there a way to authenticate durable functions monitor considering below things

• We want to use the same function app for our application functions and the durable functions monitor functions
• We don't want to set up authentication using easy auth, so don't want to set up authentication from with in portal

[ParagKale-SSE]

I went through the code and set these 2 environment variables , but still I get an error

WEBSITE_AUTH_OPENID_ISSUER WEBSITE_AUTH_CLIENT_ID

I get the error "Login Failed. Failed to load auth config. Request failed with status code 401"

[scale-tone]

Is there a way to authenticate durable functions monitor considering below things

We want to use the same function app for our application functions and the durable functions monitor functions We don't want to set up authentication using easy auth, so don't want to set up authentication from with in portal

Using both function keys and Easy Auth within the same Function App instance is not supported. Also, DfMon does not support function keys. So your options are:

1. Run a standalone instance of DfMon, pointed to your task hub(s). You can run that DfMon instance in the same App Service Plan with your main Function App - that would eliminate cost concerns (if any).
2. Use DfMon as VsCode extension.

[BalassaMarton]

Since this issue is still open - I'm currently experimenting with injecting a custom authorization middleware before DFM, and leaving DFM's built-in authorization turned off completely. @scale-tone do you think this is a viable solution?

[scale-tone]

Hi @BalassaMarton , DfMon is a set of "classic" HTTP-triggered functions, so I'd say it depends on what kind of middleware that is. If it's like this (Functions middleware) - then it should cover DfMon's endpoints. If it's like this (Asp.Net Core Integration middleware) - then most likely not.

[BalassaMarton]

Both links point to the same page. I'm trying to intercept by implementing IFunctionsWorkerMiddleware. I'll let me know how that works out.

[scale-tone]

Both links point to the same page.

Not the same page. Code is similar, but one is for Functions, another is for Asp.Net Core Integration.

Come to think of it, I believe both cases can be handled in one middleware. Just DfMon's functions would not have HttpContext (functionContext.GetHttpContext() would return null).