How to get Windows identity details while using Certificate Authentication in WCF? I am getting NULL when I use HttpContext.Current.User.Identity. Also, when I use ServiceSecurityContext.Current.WindowsIdentity.Name -- this return claims value due to certificate authentication.
Kindly advise.
Using certificate authentication,The server cannot get the windows identity of the client,only the relevant information about the certificate can be obtained.
If you want to obtain the client's windows identity on the server-side,you can consider adding a method that the client passes the windows identity to the server.
[OperationContract]
void GetWindowsIdentity(string WindowsIdentity);
This is the OperationContract of the server-side.
public void GetWindowsIdentity(string WindowsIdentity) {
Console.WriteLine("WindowsIdentity:" + WindowsIdentity);
}
This is the realization of the method.
client.GetWindowsIdentity(WindowsIdentity.GetCurrent().Name);
Client-side passes windows identity to server-side.
Related
I have set up an IdentityServer 4 application as per the following answer. The author has used X509Certificate2 in AddSigningCredential(cert). I used AddDeveloperSigningCredential() in development, which has created a tempkey.jwk file in my project folder.
I then tested this Identity Server 4 application with postman:
The above call results in the successful generation of Token. Now, I need to go into production. I have created an Azure App Service to host the Identity Server 4 application.
I have a very little understanding of Digital Certificates and Identity Server 4. I have gone through a few articles/answers but I am getting super confused. Just need to understand all of it in easy words.
My questions are:
How can I create the X509Certificate2 certificate, as done here?
How would the Client application be using this certificate?
Where is it being used in development mode, as I am not providing any Public Key in the Postman call?
How can I create the X509Certificate2 certificate?
This answer might help here: https://stackoverflow.com/a/58136780/1658906.
How would the Client application be using this certificate?
It only uses the public key from the certificate if verifying the token.
Your identity provider (your IdentityServer app) uses the certificate to digitally sign the tokens.
An app that wishes to verify a token issued by the identity provider can use the public key from the certificate to verify the token is valid.
Apps usually get the public key from the discovery endpoint: https://identityserver4.readthedocs.io/en/latest/endpoints/discovery.html.
Getting it from there instead of hard-coding the public key is best practice since it enables key rotation more easily.
The certificate's private key needs to be kept really secure.
If someone has the certificate private key, they can create any token they want, and it'll be considered valid by the applications.
Meaning they could impersonate any user or elevate their permissions etc.
Where is it being used in development mode, as I am not providing any Public Key in the Postman call?
Client apps do not use it when requesting a token.
Only if you want to verify if a token is valid.
When HTTPS performs two-way authentication,
The Server needs to obtain the Client's public key from the Client.
I have question about the Public Key:
The Client here is the browser, I want to know what's the Client's Public Key, does it refer to the Public Key of the Client's OS's? or is it mean a browser's ? if is browser's, how to check the Public Key of Chrome?
The public key of the client in a HTTPS connection is the public key of the client certificate. This client certificate needs to be specifically imported into the browser (or need to be backed by a smart card etc). Thus it neither depends on the OS nor on the browser but instead on the specific user. Therefore client certificates in HTTPS are used to authenticate users, not the OS or the browser.
I'm doing my school project and in my case, I have a client and 2 WCF cloud service in Azure cloud and the first service then needs to call another service. The client (caller) need to call the WCF service and verify the caller identity without Login, and what way can I use in this case, My idea is to use SSL Authentication or IP to verify the caller identity and is this method is correct or any suggestion method to this case?
There are multiple options for authentication. As you indicated you can use a SSL certificate to validate that the client is who you think they are (preferably SHA2 or above).
You can also white list by IP as you also mentioned. This could cause problems later if the there are multiple clients or their IP changes.
With WCF you can also use a Custom User Name and Password Validator where the client passes a user name and password in the request.
I think unless you have the option to use windows auth, tokens would be the other option, that is more complicated though. Using SSL or User Name Validator are probably the easiest to set up.
Using latest VS 2013 and Azure SDK 2.4, I've created a Web Role and a WCF service in it.
This service will be consumed by a standard generated .NET service reference client proxy.
I am trying to figure out what is the simplest way to secure this WCF service. I mean securing the authentication can not be hacked easy way, like clear text pwd etc.
Some additional info about the use case:
There will be only one user
It is completely OK to store any secret in client side (like username/pwd or certificate) because the client app will run in a secured place
I just would like to prevent my service to be accessed by the public. Only my secured place running client app should access it, I would like no more no less.
So I am googling the web, and more I read more I confused and overwhelmed with the options and possibilities what I do not need I think. When searching for client certificate I find overcomplicated federated auth methods with server side temp certs etc what I am not sure my simple use case requires.
Any help appreciated.
Thanks in advance
If you really want to restrict access then I would look at client certificates. Configuring azure for client certificates seems quite complex to detail in a single SO post so I'll refer you to this blog post client-certificates-in-windows-azure and I'll summarize below [I used this myself recently so I know it works]
In essence you can make your own certificates using makecert [NOTE: you may want an official SSL cert for your site and only use self-signed for your client certificates.]
You then configure your site to accept client certs - normally I'd use appcmd.exe and a startup task but as the blog post points out your site is not ready so instead you need to add this to your webrole OnStart method [I actually went down the appcmd.exe path initially and was very confused].
using (var serverManager = new ServerManager())
{
try
{
var siteName = RoleEnvironment.CurrentRoleInstance.Id + "_Web";
var config = serverManager.GetApplicationHostConfiguration();
var accessSection = config.GetSection("system.webServer/security/access", siteName);
accessSection["sslFlags"] = #"SslNegotiateCert";
serverManager.CommitChanges();
}
catch (Exception ex)
{
...
}
}
In the CertificateAuthHandler you can than validate the certificate and if you want (and I recommend) that the client certificate being sent is from your expected CA (if self-signed) or that the thumbprint of the certificate is the one you expect (if there is only going to be one) or a combination of the above.
I am new to WCF. I have a requirement to expose a WCF service that will validate the callers in two ways:
Clients should have a valid x.509 certificate that matches the server's version. The server should verify and understand that the caller is a valid client.
Also, the clients should supply username/password to the service. The service should look up in a custom SQL data store (NOT Membership DB) and authorize the client as per the role corresponding to the credentials supplied.
What would be the best way to design / approach the goal?