I'd like to use Visual Studio 2017 to build Azure Function App with HttpTrigger. However, I can't find the way how I could add Azure Active Directory authentication to secure the end point.
Will it work if I just add jwt token to the http request and then call ClaimsPrincipal.Current.Claims inside the method? Is there any other solution?
AFAIK, the authentication for the external identity data provider only can config on the Azure portal. And if you host the Azure function on Azure, the answer is yes. However if you host the Azure function on local, there is no way we can config for the authentication using Azure Active Directory.
As a workaround, you need to get the token from headers and verify the token manually before run the function code. And if you want to support to config the authentication for host Azure function on local, you can submit the feedback from here.
You can use the Microsoft OpenID Connect and JWT libraries to validate the token and get claims based on a received access token. Here's an example: https://github.com/azure-samples/ms-identity-dotnet-webapi-azurefunctions/tree/master/
Create an app registration in AD
Issue a browser request to get an access code
Issue an HTTP POST request for an access token using the code and the secret via cURL
Send the access token as an Authorization Bearer header to the local function endpoint
I had issues using newer versions of Microsoft.IdentityModel.Protocols.OpenIdConnect with .NET 6.0 and Azure Functions 4 and had to fall back to version 6.10.2.
Related
We've enabled authentication on our Azure api app and it's working well. Clients are required to retrieve a oauth2 token for authentication and authorization to the service. Our service is a Express Node.js application and we are leveraging apidoc for the service documentation.
I can't figure out from the authentication configuration how to allow access to a url path without requiring authentication. For example:
https://app-myservice-staging-001.azurewebsites.net/constituents should require authentication
but the documentation url
https://app-myservice-staging-001.azurewebsites.net/apidoc should not
Current with authentication enabled everything under https://app-myservice-staging-001.azurewebsites.net is protected.
Is this possible and if so where do I need to look?
Answer based on link provided by amit_g. We opted to add our excludepath directly to our authsettingsV2 config using the Azure Resource Explorer since the /apidoc/* path applies to all our services.
The app
I have a web application on Microsoft Azure. The client is written in Vue.js and hosted via a Windows App Service. The server is built using Azure Functions, and hosted via a Linux Azure Functions App.
Both the client App Service and the server Function App use built-in authentication ("Easy Auth"), with Active Directory configured as the identity provider. I am able to log into each, separately, via AD.
Until recently, I was also able to make authenticated requests from the client to the server. The client has
"loginParameters": [
"response_type=code id_token",
"scope=openid offline_access api://<Application (client) ID>/user_impersonation"
]
in its authsettingsV2 and generated tokens' aud have the correct application ID. Passing the access_token from the client's /.auth/me response as a bearer token in requests to the server used to work.
The problem
I made a few configuration changes today, tested authentication, found that it was no longer working, and backed them out. Unfortunately, reverting those changes didn't fix the issue and generated tokens are no longer being accepted by Easy Auth on the server:
{
"code": 401,
"message": "IDX10205: Issuer validation failed. Issuer: '[PII is hidden. For more details, see https:\/\/aka.ms\/IdentityModel\/PII.]'. Did not match: validationParameters.ValidIssuer: '[PII is hidden. For more details, see https:\/\/aka.ms\/IdentityModel\/PII.]' or validationParameters.ValidIssuers: '[PII is hidden. For more details, see https:\/\/aka.ms\/IdentityModel\/PII.]'."
}
Okay, so the issuer is not in the list of valid issuers. But Azure hides personally identifiable information in exceptions by default so I can't see the issuer or any of the valid issuers.
One option appears to be:
If you need to see the full information present in exceptions, please set IdentityModelEventSource.ShowPII to true
but this looks like a reference for configuring authentication myself using C#. I don't see any way to change this setting when using Easy Auth.
Maybe I can access raw logs. Let's see, I should be able to see this information by enabling application logging:
If you enable application logging, you will see authentication and authorization traces directly in your log files
To enable application logging for Linux apps or custom containers in the Azure portal, navigate to your app and select App Service logs.
But that option is not available:
A lot of the Function App documentation links to App Service documentation, so it would seem that Function Apps are a special kind of App Service App, but maybe not. The preceding quote is from App Service documentation, but I got there following links from Azure Function App documentation.
Alright, let's see if there's a way to enable application logging for Function Apps. Azure Monitor Logs look promising, but none of the generated logs appear to be about Easy Auth. I just see messages about the service starting. Maybe that's because, on Linux apps, Easy Auth runs in an isolated environment and therefore wouldn't be included in diagnostic logs:
The authentication and authorization module runs in a separate container, isolated from your application code.
So… how can I get more details about this error? Easy Auth is recommended as an option for authentication with Function Apps, and I'd hope that there's a way to get more information about what's happening.
I have seen Azure App Service Authentication / Authorization returns HTTP 401 IDX10205: Issuer validation failed and have already set accessTokenAcceptedVersion to null in the manifest. That Q&A helped me get the token passing working in the first place, and I have not changed that value.
I want to write a script that:
Logs a user into Azure AD with the device code mechanism
Constructs a SAML SSO request URL
Makes the SAML request using the auth from step 1
Gets the SAML response back, and does something with it (not just open it in a browser)
Is there a way to do that with the Azure AD libraries?
I feel like this should be possible and I’m just missing something. Any ideas?
I've tried a bunch of stuff and experimented with code in the Python library, but to no avail.
I would prefer Python, but I can run it in a Docker image so language isn’t so important.
Context
At work, we use Azure AD for authentication, and we can log into the AWS Console using Azure AD and SSO SAML.
If I construct an appropriate SAML request URL and open it in my browser, I go through the in-browser auth flow. When I’m logged in, Azure AD returns a SAML response, and eventually my browser redirects me to the AWS console. It’s a URL of the form:
https://login.microsoftonline.com/11111111-1111-1111-11111111111/saml2?SAMLRequest=<base64 encoded string>
Now I want to do a similar flow for AWS credentials – make a SAML request to log in, read the SAML response, create credentials using assume_role_with_saml, then write those to ~/.aws/credentials. I think that means I have to access the SAML response directly – the browser just drops me at the end of the redirect chain.
Any ideas?
Other ideas
I’m aware of the aws-azure-login npm package which does this by spinning up a headless browser – but it’s unmaintained and I’ve found it to be a flaky.
Right now I have a Python script that opens the SAML request in Chrome (where I log in), then uses the browsercookie library to raid Chrome’s cookie jar and use those for its HTTP requests. That works, but it feels weird to be copying cookies this way. Also, it doesn’t work if I’m ssh'd into a remote server.
I found an answer from a year and a half ago that says “ADAL.JS does not support SAML2 tokens”. Wondering if that might have changed, or am I still stuck?
No - ADAL is OpenID Connect and returns a JWT token.
Why do you need to use SAML? Could you not use OpenID Connect?
Azure AD does not support SAML tokens for the device code flow.
MSAL library from the Azure AD team supports this flow for apps. Please give this a try or you can write code against the protocol itself
I tried to implement custom Authentication via a authentication endpoint in an azure mobile app. I've created an Api Controller, that creates the Jwt using Azures AppServiceLoginHandler.CreateToken method. When I post to this controller with turned off Azure App Service Authentication, I get a token, but when I want to use it later, I always receive a "401 Unauthorized".
But when I turn the setting on in the Azure Portal, and send the very same request
I get:
The requested resource does not support http method 'GET'.
I'm not changing any code, and I'm certainly using a POST request - The exact same request, that works with turned off App Service Authentication.
My Code is essentially the same as here:
https://www.newventuresoftware.com/blog/custom-authentication-with-azure-mobile-apps
Could someone enlighten me here? Do I need additional configuration somewhere?
As adrian hall's book about Custom Authentication states as follows:
You must turn on Authentication / Authorization in your App Service. Set the Action to take when request is not authenticated to Allow Request (no action) and do not configure any of the supported authentication providers.
For custom authentication, you need to turn on the Authentication / Authorization in your app service for authenticating your token. Moreover, I would recommend you leverage fiddler to capture the network traces to narrow this issue. Additionally, you need to make sure that you send the custom login request with HTTPS. Details, you could follow this similar issue.
My question is [Similar to this one1, but with third party providers instead of active directory.
I have an end-user UWP app, and I want to consume my Azure API App. I am NOT Azure mobile app and it's client side SDK.
Most of documentation is of sort "copy paste this magic code" and never explains how authentication actually happens.
I was inspecting mobile app SDK because Microsoft's documentation says that it's auth. process is the same.
From what I see, the mobile App SDK opens a web-view very similar to that produced by a WebAuthenticationBroker. Then every request to the server is accompanied by a header X-ZUMO-AUTH and a token. It appears that this token is issued by the azure app service, not the original provider. It is much longer than the tokens issued by Twitter or Google.
At the same time when I point web-browser at the end-point and go through the log-in process, I see that the browser is using a Cookie: ARRAffinity=c4b66198677464de573103f7aa267c33ea38617020514011cea4506e0a55d9d0; AppServiceAuthSession=EIVymV
Questions:
The problem is Mobile app documentation is it just provides
instructions on how to use the SDK. I am unclear on how I would
obtain the token issued by the app service.
Everyone knows how to obtain access tokens for Google
and Twitter. Can they be used to access Azure API apps?
You are correct that API apps use the same built-in authentication as mobile apps. The basic flow looks like this:
Login to the app using provider credentials. This can be done using either a client-directed flow using your provider's SDK or can be done using a server-directed flow involving browser popups (i.e. the web view you mentioned). In the latter case, there is an endpoint at /.auth/login/ which is provided by App Service and manages the login flow for your app.
App Service will respond to your client app with a session token (a JWT).
You call into your APIs using the session token from #2. It is passed via the x-zumo-auth HTTP request header (it's named this way for legacy reasons).
The AppServiceAuthSession cookie you are seeing is the session cookie for when you use a browser to do authentication. ARRAffinity is an internal routing cookie used by App Service and is not related to auth.
If you're looking for more internal technical details on how the built-in App Service Authentication / Authorization works, check out my blog, starting with this post: http://cgillum.tech/2016/02/01/architecture-of-azure-app-service-authentication-authorization/