Microsoft Graph API and Dynamics Web Services both support certificate authentication with client credentials flow.
Are there any security concerns in "Authenticated Users" having read access to the private key of the authentication certificate stored on the IIS server? The private key is not exportable.
Are there any security concerns in using the same certificate for both SSL of the IIS site and the client credentials flow authentication?
Related
I'm having a .net core API and an EmailService as a connected service (WCF)
The EmailService is hosted on IIS (HTTPS); I'm trying to connect to the emailService with a Client Certificate. Everything is fine but i'm getting the
The HTTP request was forbidden with client authentication scheme 'Anonymous' error;
On the EmailService side:
The SSL Settings are on Require SSL (Require), the IIS Binding is on HTTPS
On the API side:
When i'm trying to access the emailservice by chrome browser, i'm getting a prompt for a client certificate, i'm picking the cert and everything works alright;
Any suggestions?
Thanks
I am not sure if you can call the service properly since WS-security is not supported in DotNet Core. Anyway, this error typically indicates that the client’s certificate cannot be recognized by the server-side when establishing the Https communication. Also, if your client communicates with the server over HTTP and the server requires SSL, this kind of error also occurred.
The Https secure communication between the client-side and the server-side can not be established properly. As you know, the https secure communication requires the procedure of exchanging each other’s public key of the certificate. Therefore, the server-side and the client-side should establish mutual trust. In other words, the server’s certificate must be trusted by the client and the client’s certificate must be trusted by the server. The specific operation is to install the certificate in the local Trusted Root Certification Authorities.
Please refer to the below link.
https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/transport-security-with-certificate-authentication
Besides, the client-side should have access to the private key of the certificate provided by the client so that the https secure communication is valid. The specific operation is to add the current user to the private key management group of the certificate.
Feel free to let me know if there is anything I can help with.
I have multiple sets of sensor networks that are sending data to a .net web api. Somehow, I need to secure some of the endpoints of the API (so that I can be certain that the information sent to the API really is from the sensors). Basic auth and SSL seems to be one way to go. The problem is that I'm having trouble understanding the SSL part.
As of now I have created a client certificate that is stored on the sensors, information of the certificate can be retrieved in the API by the Request.GetClientCertificate() method. Is this overkill when I just want to secure my Api with basic auth? That is, is the communication secure by just sending data over https without providing a certificate?
I do not need to use the certificate for authentication (since this is done by basic auth).
Basic authentication is about sending the user name and password in the HTTP authorization header as plain text (base64 encoded but not encrypted). For this reason, you need to use HTTPS with basic authn so that folks in the middle do not get to see the user name and password that a client sends.
When it comes to HTTPS, there is a server certificate and a client certificate. Server sends the server certificate to the client so that client can determine it is the right server it is connecting to. Similarly, a client can send a client certificate to the server so that a server can determine if an authentic client is talking to it.
The client certificate part is optional in HTTPS. So, you can use basic authentication without using the client certificate. If you use client certificate, it is already a credential and you need not use basic authentication, unless you want to use a two-factor authentication. TFA is an overkill or not - it is for you to decide.
I am studying brokered authentication, federation etc. On all the blogs, it's mentioned that there is a "trust" between Security Token Service and other web services. However, I could not find a blog which explains how to establish that trust.
Questions:
Which thing makes other web services trust the STS? i.e. how do we establish trust between STS and other web services?
How do other web services verify that the security token is issued by the STS they trust, and not by some other STS?
I understand that various technologies would be doing it in different manner. It would be good if someone explains how it happens in the .NET world (using WCF, Windows Identity Foundation etc.).
It's done using the X509 Certificate.
SecurityTokenService (STS) "signs the SAML token" using a certificate which is trusted by other services too. So the trust is established using the common thing, i.e. the certificate, which STS, and other services also trust!
While calling other web services, SAML token issued by the STS is sent through the SOAP header. If the SAML token is signed by the certificate your other service trusts, then your service understands that the token is issued by the 'trusted' STS.
In Windows Identity Foundation, you can configure the signing certificate for STS.
In case of other web services, the trusted certificate can be configured in the Service Host using ServiceCredential class.
Do not really know how x509 works.
If I have a Web Service that needs to authenticate and validate the client, and he uses a ClientCertificate, could he send me some information that I could then validate against?
I do not create the Web Site itself so I can't be sure they would do it right. I don't wan't to allow someone to say to the Web Service "It's okay, I ClientCertificated him and he's good".
You can implement your own custom client certificate validator but its usage will be different based on the way how do you use the client certificate. If you use pure message security your validator will be the only component used to validate the certificate. If you use HTTPS with client certificate (transport security) the certificate will be first validated by Windows (= your service hosting server must trust the certificate) and after that it will be passed to WCF and validated by your validator.
I have two WCF Services using WsHttpBinding with transport security mutual certificate authentication that are being hosted on the same windows server. Clients that can access one WCF service should not have access to the other WCF service. I need some help on configuring the client certificates on the windows host. The client certificates are signed by trusted CAs and the intermediate and root certificate chain is already installed on the the server. It seems like the service automatically relies on chain of trust and does not require the actual client certificates installed on the server at all before letting the client access the service - this is not the behavior I want. Can someone please tell me how I should be configuring these client certificates in order explicitly allow access to one service and not the other?
Thanks.
That has nothing to do with certificates themselves. When using mutual SSL authentication certificates are used only to authenticate client and the authentication is done outside of your application (this is difference to message security where you can create custom certificate validator). Once certificate is trusted client is automatically authenticated to anything on the server using certificates for authentication.
You are looking for authorization - the step where you define what can authenticated client do with your service. You can either hardcode your authorization logic into your service by using role based security or you can implement two custom ServiceAuthorizationManagers and assign each to single service.