I have a client that wants to implement CAC with our website. Usually the user already has access based on the certificates assigned to them.
They want to be validated by entering their CAC pin code when they click a button to log in.
I'm using ActivClient to manage the CAC but I don't know how to have the website communicate with the card reader to have the user input the pin code and validate it.
Is this done through IIS settings or do I have to update my code to somehow communicate with the middleware?
Thanks in advance
The solution we used involved a few configuration changes to IIS as well as some code changes to use the information provided by the CAC.
In IIS (8.0), we just set the Authentication to Anonymous Authentication. In SSL Settings, we checked Require SSL and under Client Certificates, select the Require option.
After you've authenticated, depending on what information you need access to from the certificate, you can access it using this method:
X509Certificate2 certificate = new X509Certificate2(Request.ClientCertificate.Certificate);
This will give you the certificate object that contains the information that the CAC carries. You can access some of these properties by using
certificate.GetNameInfo(X509NameType.SimpleName); //X509NameType.EmailName, etc
I recently dealt with this with the DoD. There is no code involved, all you have to do is set the the IIS site to use Integrated Security (or possibly certificate authentication based on your AD configuration) and turn off the other authentication mechanisms. The browser will then prompt the user for credentials using the method configured in Active Directory, which should show the CAC certificate selection and PIN window if they are using AD correctly. Note that you must also be using HTTPS or the browser will not pass the CAC credentials to the server for security reasons.
Related
On a Certificate provider, StartSSL, when you register, you put in your email and a password. They generate a certificate (.pfx) which you need to download and install into your browser.
Which was pointed out in comments that it is a Client Certificate.
So when you click login, in Chrome for example, a window popups and asks you which certificate to use. I could have several client certificates and log into separate accounts based on what I select. They warn that if you loose the certificate then you can't log in to the site without them regenerating a new certificate.
I am would like to do this using C# - I would like to generate a client certificate and then use it later to log in as admin without typing in a password.
What are the mechanics of this? How can generate certificates and use them to log in to my site? I would like to do this on a MVC C# site. I don't mind if I need to generate self signed certificates, its only for my own use. At least it gets rid of password forms and brute force attacks.
This is fairly simple, the certificate requirement is an option of the SSL handshake.
First you need to go to SSL options on IIS and check the option to accept and require certificates. This is enough for browsers to automatically pop up the cert selection window and the communication is mutually secured by both server and client certificates.
https://technet.microsoft.com/pl-pl/library/cc753983%28v=ws.10%29.aspx
Then comes the request pipeline. You either need a httpmodule or you just provide a handler for the global application's AuthenticateRequest event. There, you refer to the Request.ClientCertificate
https://msdn.microsoft.com/en-us/library/ms524668%28v=vs.90%29.aspx
You read the certificate's unique properties, for example the thumbprint and you use your local database to find a user record that corresponds to the certificate and you set up the Principal for the request lifetime accordingly.
Our client requested from us to make our web application accessible from Intranet and Internet.
When user tried to access the website from Intranet, The user should be logged in immediately (Windows Auth) ... The user should have public access also (e.g. Home, Coffee shop), But in this case he should use his credentials and the server will check if its valid.
Any advises?
This is the standard way Integrated Windows Authentication works. If you're inside the intranet (logged onto the domain), IE will automatically send your credentials when the website returns 401.2 (no auth method specified). When you're not inside the domain, the credentials will have to be prompted for, since the domain server cannot be contacted from the client machine.
This is not the same as the "tricky" solution you referred to. That solution is tricky because it also uses forms authentication, which you don't need here (AFAIK).
We decided not to use Windows Auth at all.
The customer want to stay logged in if he is in the Intranet.
so we did the following (and the customer is ok with that)
Forms Auth + 'Keeps me logged in' checkbox
Validate Credentials with AD.
Check if User in trusted IP Addresses Range (Something like allowed IP addresses in SQL Azure)
If trusted IP Range, user becomes authenticated.
If its not, Two factor auth by sending SMS.
One more reason for not using Windows Auth.
The user want to log-out at anytime to use different credentials to do some special tasks.
Usually customers do not know what exactly they want, so we will start dreaming and make things complicated. 'Simply keeps me logged in' for trusted IP addresses and he will stay logged in for N days.
I am working on one project where we have to deploy two different application on server, one is Cognos website and other is .NET website.
Now, when request come to web server (IIS) it should asked for Client Certificate Selection, once you choose the client certificate it should go back and check where it is attached with any Active Directory Users or not.
basically i wanted to implement authentication using Active Directory and Client certificate using .NET.
Appreciate for any suggestion/direction.
This should work out of the box with no code.
First, turn off anonymous access and basic authentication for the website and turn on integrated windows authentication and certificate integration.
Then, in your asp.net application, set the auth mode to windows.
Then, turn on SSL for the website and check the option "require client certificate".
http://technet.microsoft.com/pl-pl/library/cc753983%28v=ws.10%29.aspx
From now on, when the browser supports certificate integrated authentication and the client machine has the certificate either in the user store (IE) or in the browser store (other browsers), the browser will automatically ask the user to pick up the certificate.
My advice is to start with integrated windows authentication over SSL but without certificates (do not check "Require client certificates"). Test with IE and configure the IIS until your users are automatically authenticated without any prompt for credentials.
This is the most troublesome part. If you have it working, you just turn on the requirement of client certificates.
I have a third party web application and now my manager wants to add smart card authentication to some of the pages (not the whole application) and return certificate information. What I'm thinking is to add buttons to those pages, and in the onclick event, I will do the client certificate authentication (where a certificate selection window will appear followed by the "PIN" window) and return certificate object for further processing.
I initially thought about a web service to do the client certificate authentication and return certificate information, which would be great because we might consider using that web service in other web applications (on different platforms). However, I couldn't find any code example that did this. Then I found the IIS solution.
I have now created a separate folder with a page that requires a client certificate. On the button click event, I redirect to that page. Then on that page, I retrieve the certificate information using the X509Certificate class. I don't think this helps me in what I'm trying to do, or at least I don't know how it helps.
So my question is (sorry for the long background description)
How can I redirect back from that page with the certification result?
If possible, any reference on how to build up a web service that does the client certificate authentication in the same way that IIS does?
Thanks
Update
I looked around and still don't have a clue on how to achieve this. I'm not sure how to code at SSL/TLS handshake stage for the web service. I don't know how to return the certification back to the page I invoke this function either. So what I'm trying to do now is to redirect from a protected page that requires client authentication. It seems the web server caches the authentication result. Here is my third question, I hope someone can answer.
How can I clean out the authentication result at the end of the page session so that each time the page is visited, it request client authentication (where a certificate selection window will appear followed by the "PIN" window)?
if your app is hosted in IIS then simply add (in web.config) a section that says client certificate is required for those pages. THe browser will then ask the user for a cert.
Windows has a caching feature which, by default, allows applications to access the private key for a limited time after the initial PIN prompt, or until the application is closed completely.
To disable, set this registry key. (Or use a GPO)
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography]
"PrivKeyCacheMaxItems"=dword:00000000
"PrivKeyCachePurgeIntervalSeconds"=dword:00000000
I'm trying to select the correct authentication mechanism for a WCF service. This article explains what the supported credentials are - I just don't understand how to decide between them.
Please could somebody supply an explanation of when each of the authentication options are appropriate to use, and the advantages/disadvantages of each over the others.
For reference, the authentication options are:
None
Basic
Digest
Ntlm
Windows
Certificate
Password
Note: I have seen a great MSDN article on this, but I cannot for the life of me find it anymore.
None:
Pretty straightforward - use this when you don't want to identify or authenticate your users.
Basic and Digest:
These authentication types aren't used much any more, but occasionally you might need to connect to an older web service hosted in IIS, which might be configured to use Basic or Digest authentication. Traffic won't be encrypted. For Basic, the password will be sent in plain text, and for Digest the password will be sent in a poorly encrypted form. Avoid using these authentication types.
NTLM and Windows:
NTLM uses the NT LAN Manager to control security. Windows, by default, will use Kerberos (ie Active Directory) to control security. If Kerberos is not available, it will default to NTLM. Only use NTLM if you specifically need to avoid Kerberos (I cannot think of a scenario where you would want to do this, but part of WCFs greatness is its flexibility).
Certificate:
If your users have their own certificates which can be used to identify them, you might consider using this authentication mode. Passwords can be guessed - it is very hard to guess a certificate, so this is a pretty secure mode of authentication (provided the certificate itself is secure).
Password:
Use Password when you want to create your own method of validating a users username and password. This might involve accessing an existing user credential store in a custom database. You will need to write your own UserNamePasswordValidator - example at http://nayyeri.net/custom-username-and-password-authentication-in-wcf-3-5.
To summarize, I usually choose Windows as the authentication mode. It is secure and simple and works for most people in an enterprise environment. If you're creating a new service and for some reason Windows cannot be used, go for Certificate or Password. If you're hooking into an older SOAP service hosted in IIS, you may need to look at using None, Basic or Digest.
Although I asked this question I will add what I know about Certificates as this is something I have worked with - though if my understanding is imperfect, I'd be happy to be corrected.
An X.509 certificate consists of a Public Key and a Private Key and issued by a trusted Certificate Authority (you can self-sign a certificate, this limits the usefulness of the certificate to trusted sources only). The CA will charge a fee for the certificate, and it will expire after a period of time.
The Public Key does not need to be protected and is given to the server. The Private Key is kept private and is used by the client. Messages encrypted by the Private Key can be decrypted by the Public Key.
A request from a client has a digital signature embedded in the SOAP. This is generated using the Private Key. When the server receives the request, it uses the Public Key to read the signature. If the signature can be read, then the request is considered genuine.
Within Active Directory, there is a mechanism whereby an X.509 certificate can be mapped to a user account, so you can impersonate a user with a certain permission set based on the X.509 authentication.
The benefits of X.509, are:
that it can be used across domains; and
that the Private Key can be securely stored in the client's Certificate Store. So there is no .config file containing credentials.
Failure to control the distribution and storage of a Private Key is akin to writing a username/password on a post-it note and sticking it on your monitor.