I'm working on securing some Azure Functions endpoints. I tried with Certificate, but I hit a few walls
In the FunctionsStartup (from which derives my startup) I could not find a way to connect my AddAuth and Auth methods/classes. (I tried to search, read more on this topic, but all the answers were either for web API other type of Authentications)
I tried to check for the existence of a certificate at least, but that didn't worked either. I tried to get the certificate from request-context-connection-ClientCertificate or to read it from headers. Didn't worked locally or on deployed version. The certificates are always null.
I saw that there are some options to secure it with AD(also with facebook, google and so on), but first I'm curious if someone successfully implemented another Auth method, more like in a classic web api approach (JWT tokens, certificate, other similar stuff)
Access restrictions enable you to define a priority ordered allow/deny list that controls network access to your app. The list can include IP addresses or Azure Virtual Network subnets. When there are one or more entries, there is then an implicit "deny all" that exists at the end of the list.
Also you can request a client certificate when the client request is over TLS/SSL and validate the certificate. This mechanism is called TLS mutual authentication or client certificate authentication.
First, your App Service plan must be in the Basic, Standard, Premium, or Isolated tier.
Secondly, enable client certificates:
az webapp update --set clientCertEnabled=true --name <app_name> --resource-group <group_name>
Finally, Access client certificate. App Service injects an X-ARR-ClientCert request header with the client certificate. Your app code is responsible for validating the client certificate.
For more details about how to configure TLS mutual authentication for Azure App Service, please refer to this article.
Related
There is an example in gRPC:
Channel channel = new Channel("127.0.0.1:30051", ChannelCredentials.Insecure);
it works. Now I would like to authenticate the user on server either using the login / password pair or using Windows trusted authentication.
The authentication documentation https://grpc.io/docs/guides/auth/ shows some examples:
either with some PEM certificate that has nothing to do with windows account
or with a "trusted" authentication, but not in the meaning that one Windows computer trusts to the other Windows. The meaning is that credentials are trusted with Google.
Is it possible to do Windows-trusted authentication between two Windows PCs using gRPC?
I believe client-side SSL is what you are looking for: https://grpc.io/docs/guides/auth/#using-client-side-ssltls
You want to authenticate both ends of the connection. This won't be a simple task, since you have to manage and update certificates in clusters.
If what you are looking for is Windows account specific integration, I don't think gRPC is providing one today. You may post a feature request to https://github.com/grpc/grpc/issues.
I'm trying to figure out how to set up my Azure Web App to require client certification. The idea is to force the client's browser to send a SSL certificate (that's installed on their machine) to the web app. The web app then validates attributes in the certificate to make sure the client is authorized to access the web app.
The purpose is to enhance the security of our web app since user cannot login from a device that doesn’t have the SSL cert explicitly installed (even if they have the username/password somehow).
I'm not sure where I should begin with this. I understand SSL handshakes and the highlevel concepts but I don't really understand how to implement this in my current ASP.NET MVC web app. A tutorial that would point me in the correct direction would really help out. Or even the steps required to achieve this as I am not sure where to begin (setting up SSL certificate with IIS? Getting client to send the SSL certificate? Where did the certificate come from?) All of these questions...
UPDATE: I found this article:
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-configure-tls-mutual-auth
But I don't know where to begin...
I have an ASP.NET MVC web application that I deployed to Microsoft Azure as a Web App. In that application I have some Web API endpoints that would be only accessible if the user has the correct certificate with the allowed thumbprint. However, I have other endpoints as well (and of course the website) that would be accessible without a client certificate.
I know there is a possibility to set up the Azure Web App to require client certificate through a HTTPS connection. But if I make the mentioned REST API call
ARMClient PUT subscriptions/{Subscription Id}/resourcegroups/{Resource Group Name}/providers/Microsoft.Web/sites/{Website Name}?api-version=2015-04-01 #enableclientcert.json -verbose
that will cause that only those users can visit my site and use the Web API endpoints who has client certificates.
If I open my locally installed IIS Manager, I will have an option to Accept client certificates, not to require them, as you can see in this image:
My question is how can I set up my Azure Web App to accept (not require) client certificates? I searched over this site and many other forums, but I cannot find a way to set up Web Apps in this way.
Update:
My question is how can I set up my Azure Web App to accept (not require) client certificates?
It seems that it is not supported on azure now. I also find the support optional client certificates for TLS mutual auth feedback. And now it is underview by Azure team. You also can vote it up.
We also could remote to the Azure website using IIS Manager to set up it, you could get the detail steps from this blog.
**Prerequisites**
>On Window client OS - [IIS Manager for Remote Administration][3]
>On Windows Server – Make sure you have installed IIS Management Console.
Refer to step 6 in http://www.iis.net/learn/install/installing-iis-7/installing-iis-on-windows-vista-and-windows-7 - “IIS Management Console” is the required feature.
There's a load of stuff to cover, so I'll try to keep it structured, as all good programmers should.. bear with me.
My Environment
.NET 3.5 SP1 Smart Client
Uses WCF+SOAP over HTTP to communicate to server for business logic / data access
Typically uses a custom (username+password) or Windows authentication scheme
Current work aims to extend to include a new Claims-based authentication scheme to facilitate SSO with ADFS
So far...
Main service endpoints using ws2007FederationHttpBinding bindings, configuration set up with Message security via trust/13/issuedtokenmixedsymmetricbasic256 ADFS 2.0 endpoint
Issuer endpoint configured with IssuedTokenOverTransport to HTTPS trust/13/usernamemixed ADFS 2.0 endpoint
Service has federateServiceHostConfiguration service behaviour specified
Created temporary certificate authority (CA) cert
Created temporary certificate signed by CA
Installed certificate (including private key) and made available to IIS app pool process account
Updated service WCF config to use X509 certificate
Client modified with new app’s own Client scheme/mode, programmatically sets up channel factory to ignore errors caused by temporary certificate and disables certificate revocation checks
Username/password credentials are successfully added (via standard WCF ClientCredentials object) to SOAP envelope of token requests
Token is successfully generated by usernamemixed endpoint and is returned to the client
My problem
Immediately following the token being issued, the subsequent call to issuedtokenmixedsymmetricbasic256 endpoint fails with generic error message that the security of the message could not be validated. Inspection of the SOAP envelope result gives no information at all beyond a simple ‘failed’ result enumeration value
Full tracing has been enabled on ADFS 2.0 server, but no events are logged at all in Event Log or event traces to further diagnose
Unable to configure to work in a federated manner thus far; token is successfully issues over usernamemixed endpoint in the ‘test’ environment (the internal ADFS server rather than a remote one). Use of the ‘live’ environment gives a simple unexplained 401 HTTP status code whether using usernamemixed with confirmed and valid credentials, or windowsmixed, when trying to obtain a token
Generally: Resources from Microsoft or other sources are either very scarce, very specific to one situation, and in a couple of cases, completely wrong or misleading
So ask a question already, doofus
Why does the call the issuedtokenmixedsymmetricbasic256 that WCF makes after getting the token fail? How can I diagnose the result? Other than what I've already done - enabling all trace flags in the service host config, checking the event log and event tracing data, what can I do?
Note, if you're about to suggest a link to a screencast/guide/blog/seemingly all-encompassing MSDN article, please stop. I believe I have found them all, tried them all, and what I need at this point - if you can help me please - is an answer to the above question. Not a general resource.
I'd like to use client certificates to verify the identity of administrative callers to my web service. Then I can issue certificates only to the people I want to call my web service and be pretty sure noone else can call it. This is in a very controlled scenario where only one or two people will get the client certificate, so distribution isn't a hard problem.
This article provides a good example of how to call a web service using a client certificate.
But how can I check details of the client certificate from within my web service? This old article talks about configuring IIS to do it, but I'd like to do it programmatically within my app. I think?
thanks for any suggestions!
The incoming Request has a ClientCertificates collection that you can interrogate -- you can check the various fields in the cert or check the actual raw byte data (perhaps against a datastore or other source) if you want to completely validate it.
Note, if you issue the certs from your own private CA, you will need to install the CA's cert on your webserver into a store that is visible to all users, otherwise IIS won't request those certs from the user (due to the nature of how the server/client interaction works.)