I was reading an article about authenticating User with certificate to WCF service. Please correct me if I'm wrong. As per my understanding each user need a certificate to authenticate. How feasible is this in real world where, there are multiple clients? Is it good option to adopt?
Yes each user should have his own certificate. Certificate is used for encryption and signing (asymmetric security) and it can be used also for authentication. Authentication can be also provided by another supporting token but that is not supported by default WCF bindings (you must create your own).
To support such scenario you usually need your own certificate authority (CA) which will issue certificates to clients. It can be either use in corporate network where computers usually trusts corporate CA or it can be used over interned but CA's certificate must be issued by well known and trusted certificate authority (like VeriSign).
It is of course feasible in some scenarios. For example banks using client certificates plus some supporting token for connection to internet banking (that is usually web application scenario and not services but it is good B2C example). It is also sometimes used for communication among business partners (E2E / B2B).
Related
According to my understanding, when we are trying to connect to a website/url, even if one of the certificates in the SSL certificate chain of the website is present in the trust store then connection is established successfully. But, I want to establish a connection only if the domain level certificate is present in the trust store. And I am not allowed create a new trust store instead need to use the default trust store. How can this be implemented in Java? TIA.
Unfortunately for you, that's not how PKIs were designed to work. The search for any trusted root certificate in the chain is a design feature of PKIs that ensures we don't have to install a certificate per domain on clients - bloating local trust stores with millions of certificates and complicating revocation and renewal of certificates.
What you're looking for is referred to certificate pinning where the client validates that the certificate presented by the server has a specific thumbprint it knows and trusts before continuing any further communication with the server on the other end. It is essentially the client authenticating the server.
Depending on your particular implementation, the validation logic can be done in the application instead of at the TLS/SSL protocol layer, meaning you can do as much (CN, Key Usage Attributes, SAN) or as little (just thumbprint)validation as you want , but typically certificate thumbprints are used since they are *guaranteed to be unique. A interception proxy or other man-in-the-middle for instance can create a certificate with valid CN entry for your domain (valid domain validation), but they cannot spoof the thumbprint.
A certificate is a unique token issued to a particular individual. It is a form of identification, similar to a government-issued photo ID which most people carry.
Certificates were designed for one purpose - to convey an identity which can be verified as authentic. It does this via a chain of trust. If a client or server trusts the issuer of a certificate, then it will automatically trust the certificate.
Put in similar terms, this is similar to the TSA specifying guidelines for which forms of identification it will accept before it will let you into the security checkpoint. As long as you possess one of those valid forms of ID, the TSA will let you through. This is how the PKI is designed, and it has to be designed that way to function efficiently. So, there is no way to do this explicitly in the PKI framework.
What you're instead asking for is a separate level of identify verification beyond what PKI provides. A possible solution could be certificate pinning, but I'm not sure this gets you anywhere. If the private key is compromised, which is probably more likely than compromising a trusted CA, then you haven't gained any additional level of security.
Instead, best practice is to implement multi-factor authentication. Using the certificate itself as a second factor really doesn't make a whole lot of sense, because it isn't truly a two-factor identity. Instead, it would make more sense to use the PKI as-is, and establish a second authentication mechanism via TOTP or some other independent token generation.
I have an organization certificate that needs to be reissued due to the browser distrust (Chrome/FF) of RapidSSL certificates issued prior to a certain date. Reference: https://knowledge.digicert.com/generalinformation/INFO4627.html.
However, we have an in-house SSO setup (SAML 2.0) using the same certificate for signing with our clients. I'm evaluating whether the revocation and reissuance of the certificate will compromise our SSO setup and the new public key would have to be passed onto our clients. From what I can see it shouldn't since the certificate isn't actually expired. I would see it akin to using a self-signed certificate. Am I going about this correctly?
SAML2 uses the certificate format as a convenient way to convey keys. The trust in the certificate is based on a direct configured relationship with the Idp, not through the public CA Root system.
This is what the SAML2 Metadata has to say about certificates:
As a concrete example, no implications of including an X.509 certificate by value or reference are to be assumed. Its validity period, extensions, revocation status, and other relevant content may or may not be enforced, at the discretion of the relying party.
While it allows the relying party to do additional checks, it does neither require, nor guarantee that any such checks will pass.
Generally I'd say that continuing to use the certificate should be fine, but you need to verify with your configured relying parties (Service Providers in normal SAML2 terms) that they do not validate the certificate.
I'm new to all this security features, and recently I was asked to look into ADFS 2.0. I found ADFS uses the following types of X.509 certificates to communicate with Relying Party (RP):
Common for all RPs:
1) Service communication
2) Token-signing
3) Token-decrypting
Specific for RP:
4) Encryption certificate
Help me out please to figure out which one is really important and needed in a real-life production scenario where all 3 parts are involved: user, service provider (our company), IdP(ADFS) (on customer's server).
1) What I found regarding first certificate in MS help: "This is the same certificate that a federation server uses as the SSL certificate in Internet Information Services (IIS)" I'm not sure it's true coz I was able to replace them separately not affecting each other so they definitely might function in parallel. So no idea what this certificate is needed for.
2) Second one is for signing up issued tokens so that RP is able to make sure the token is really issued by trusted ADFS, not intercepted, right?
3) Third one is probably for reverse purposes: ADFS makes sure the message is really from trusted RP.
4) Encryption certificate for specific RP helps encrypt whole message (token), so that even if you got https public key and intercept a message from ADFS, you can not read it not having other public key which supposed to be only know to RP, correct?
Correct me if I'm wrong please.
All this certificates are optional and Micorosoft says nothing about importance of which, the only mention I cound in WIF SDK help saying it's better to use token encryption certificate in real life. The thing is we have HTTPS protocol being established for ADFS-RP communication (IIS is set up to use https on both sides). Is not it enough for secure communication? I wonder: do we really need 2), 3) and even 4)?
In a real life scenario, you have at least two:
1.) SSL certificate - just common sense nowadays, and recommended by the SAML 2.0 SSO profile. This could be the same certificate as IIS that's front-ending ADFS.
2.) Token signing / verification (not "decrypting") certificate - required to conform to SAML 2.0 profiles that use "front channel bindings" (HTTP Redirect/POST). If you're the Identity Provider (IdP) then you'll have the private signing key - if not, just the certificate (w public verification key). Indeed this is to verify that the assertions have been issued by a trusted party, and not tampered with. It is absolutely critical for federation otherwise anyone can forge their way into your environment (as the SP (RP)).
An encryption certificate would indeed be used to encrypt portions of your SAML messages - which is common if you're trying to hide information that may be passed via a user's browser (like sensitive attributes within a SAML Assertion's Attribute Statement).
1 and 2 are mandatory.
ADFS will not let you add a RP binding via importing metadata if it's not a https connection.
The definition of a claim is "A statement about a subject; for example, a name, identity, key, group, permission, or capability, made by one subject about itself or another subject. Claims are given one or more values and then packaged in security tokens that are issued by a security token service (STS)". To ensure the validity of the token it needs to be signed.
Whether the token itself is encrypted depend on the security requirements.
I'm implementing a client with python's twisted that checks the server ssl certificate when connecting, following basically this recipe. I've seen in many HOWTOs such as this one the server checking the client's authenticity through a ssl certificate as well. Currently i authenticate my clients using an unique id and 1024 char string (they are automated clients without human interaction).
What I don't understand is what reason would I have to use the whole ssl thing for this instead of just sending the "password" to the server. After all the connection is already ssl encrypted, checking the server certificate and everything. This is a similar question but I want to know why people use ssl client certs and not just what is the best way to do it instead.
A client certificate restricts access to people authorized with certificates. Assuming your certificates are distributed and managed correctly, this makes it more difficult to connect from an unauthorized location (or say, a bot network), since you need more than just a username and password.
Client-side certificates are a potential part of a defense-in-depth strategy, if you are in an environment where you can manage client certificates.
Certificates are easy to revoke. Passwords can be stolen, but stealing a client side certificate would be much harder.
Using client certificate based mutual authentication prevents at least the following attacks/problems:
Phishing the password
Key logging the password
Shoulder surfing the password
Guessing the password
Password reuse on several services
Additionally, using client certs gives you the possibility to store client certificate (and the matching private key) on a smartcard, USB token or other hardware security module (HSM), thereby going from "something you know" (password) to "something you possess physically" (token, card) plus "something you know" (PIN). This is also called two-factor authentication.
In your specific case of using passwords as shared keys in a technical, system to system communication link, using certificates has two advantages:
scales better: with shared keys, every node has to share a different key/password with each other node, resulting in (n-1)! passwords, while with certificates, each node needs only one certificate and private key (n certificates plus a CA)
the possibility of storing the key on a HSM and thereby prevent it from being copied/stolen digitally.
The main advantage of client-side authentication (i.e. when server checks client certificate) is that if server gets compromised, the client's secret, which is private key for certificate, won't be compromised. Whereas if client uses credentials they could be compromised along with server.
Owning SSL certificates that are signed by a certificate authority means that the SSL certificate owners have gone through the hassle of being verified by the CA that the owner is who they say they are. For instance, if you have an ecommerce store called widgetsdeluxe.com and you have a certificate for the domain widgetsdeluxe.com that has been signed by Verisign, et. Al., shoppers will know that when they go to that site and the name on the certificate matches the actual domain name they went to, then they can trust that the information is secured and is coming from the widgetsdeluxe.com domain (this is to prevent spoofing and man-in-the-middle attacks).
I have a client/server WCF application that needs some sort of user authentication against a database. The application (both client and server together) is being developed to be sold to dozens of customers, for use on their intranets. We're not too worried about encrypting most of the data moving across the wire, except of course during authentication.
Thinking about WCF security, I keep coming back to the idea that we should be making use of x509 certificates. However, our customers will definitely not want to know about any of the details of having to apply for, purchase and install these certificates.
I'd like to know first of all what the preferred method is of implementing username/password authentication in this scenario. If it will require using certificates, must the customer apply for their own certs from a trusted CA, or can we as the software provider generate certificates for the customer to use?
Really I'm looking for a best practice, with the least friction to our customers.
Thanks!
Edit: I'm using NetTcpBinding, and my server is running as a Windows Service.
So username/passwords does not require client certificates as I'm sure you're aware, it simply requires an HTTPS certificate on the server hosting the WCF service - once you have that you can happily use the standard username/password auth bits (WCF will not allow message based authentication without HTTPS).
If you wanted to head down the client certificate root you get the advantage of non-repudiation - you can be sure that the machine sending is who it says it is (unless someone has stolen the certificate, which is less likely than a username and password combination going walk about). You as the software provider could act as your own certificate authority and generate your own client certs (there are a few ways to do this depending on your infrastructure) but then you need to configure the clients to trust your root CA.
If the server and client are running in a domain environment you could use transport security with Windows authentication (you're using tcp binding, so interoperability is out the window anyway!) The added bonus to this is the authentication is transparent and you don't need any certificates anywhere. If you want verfication of the server identity then message security with Windows authentication will do the trick.
I've got project in production which is similar to your scenario. I have a Windows Service hosting endpoints via netTCPBinding and I used x509 certs... although in my case, the intent was to encrypt both the transport and message layers, as I was crossing over untrusted security boundaries. I was less concerned with providing authentication/authorization other than requiring the certificate be present.
Similar to your intranet scenarios (I'm assuming), I had authority over the server and client machines at installation time... or at least could dictate some of the terms of installation.
Rather than purchase the x509 certs and burden the client with that expense, I opted to roll our own. We set up one of our Win2003 servers to be a CA, issuing our own Certification Authority cert. We then generated an x509 cert for the server, as well as individual x509 certs for the clients.
The client and server certs were installed on both clients and server (as appropriate) into the personal user store at the computer level. We also installed our CA cert directly into the Trusted Root Certification Authorities section, thus making our client and server certs trusted.
Because I was less concerned with authentication/authorization, I don't know what to recommend as a best practice for dealing with binding certs to individual users and going more granular than machine-level (my solution was windows service to windows service communication -- completely unattended). I would think you'd need a cert for each user, installing it into their personal user store in the certificates MMC. The runtime implementation will be guided by how you configure WCF to do the cert lookup, so it should be fairly easy.
Throughout the process, I relied heavily on what I'd learned from this great CodeProject article: Securing WCF Services with Certificates. It walks you through generating/installing the certs. The sample WCF applicatoin is IIS-hosted, but I was able to pretty easily translate the config sections from web.config to app.config.
In my case, I exposed the Web interface for requesting certificates in Win2003 to the web itself, so the client could request certificates directly in the future. We have approval control, so it works well. I haven't had a need to generate new certs yet, so I can't say how much friction that would entail.
If your going to be crossing firewall boundaries then certificates are going to be your best solution. I don't know much about the specifics about applications for certificates or your application. Unfortunately, as far as i know, i think you will have to help them apply for certificates or they will have to do it their self unless they want to undertake in the process of installing their own certificate server. If the app will be internal then windows authentication will work and is VERY easy but if you think your going to have clients that user your application across firewall boundaries then you might as well invest the time in using certificates because certificates will work everywhere. Now there is something called federated security where you delegate the permission of authentication to another entity. I think this is used if say you have to domains and you want to delegate permission say of someone on another domain that is not on your domain to their domain but its pretty complex and my understanding of its very limited but by the sound of your requirements certificates is the way to go.
Security is not supposed to be easy :)