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.
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.
We are testing our own OIDC-IDP with a commercial client. (We don't have access to the clients code.) After some tests, the client always returns
OpenID Connect token validation failed: Token signature invalid (ID_TOKEN)
The IDP is in the wild of the web, the client is in our own network with a SSL breaker in between. We have a test client, also in the WWW, which works fine.
My question is, which certificate does the OIDC-client use to verify the signature. Is it the certificate of the website of the IDP? If so could it be that the reason for this error, is the ssl-breaker replacing the original certificate?
Note about OIDC lingo
OpenId Provider (OP) is analogous to SAML2 IdP
Relying Party (RP) is analogous to SAML2 SP
I knew what you were referring to when you wrote "IdP" and "client", but I want to mention that you'll commonly see OP and RP used for OIDC documentation / discussions.
Context and suggestions
The commercial RP you're testing with states that signature verification of the ID Token (i.e. JWT) is failing. To specifically answer your question, no, it is not using the x509 cert from the OP website to verify the signature. The key the RP uses to verify signature will depend on whether you've configured your OP to sign ID Tokens using:
HS256 (symmetric key algorithm); or
RS256 (asymmetric key algorithm)
Please have a look at the accepted answer on this thread for context:
RS256 vs HS256: What's the difference?
In the former case (HS256), your OP signs the ID Token with a secret key. And your RP must verify the signature using that same secret key. (NB: as you probably know, it's important to keep this shared secret key safe and secure.) If this is your environment, perhaps the commercial RP has a configuration option that allows you to upload or copy/paste in the secret key.
In the latter case (RS256), your OP signs the ID Token with a private key, but your RP verifies the signature using its public key counterpart. If this is your environment, perhaps the commercial RP has a configuration option to specify "jwks_uri" and "kid". These refer to the URI that your public key is published to, and its key ID, respectively.
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.
Don't know much about encryption...
Say I'm preparing a SAML request to submit to an identity provider. Why would I need to apply an x.509 certificate to this request? Is transmission over SSL alone not secure enough?
In the case of SAML, message-level security (i.e. the XML itself is signed and sometimes encrypted) because the communication involves parties that don't communicate directly. SSL/TLS is for transport-level security, only used between the two parties that are communicating directly and for the duration of this communication only.
Depending on which SAML binding you use, the dialog can look like this (e.g. along the lines of Shibboleth):
User's browser connects to Service Provider (SP)
SP gives the user a SAML request, not necessarily visible, but hidden within a form or equivalent.
User's browser (in a direct connection to the IdP) sends the SAML request to the IdP.
The user authenticates with it and gets a SAML response back.
The user's browser sends that SAML response to the SP.
In this scenario, there is no direct SSL/TLS connection between the SP and the IdP, although all 3 parties are involved. (Some variants of this involve a back-end communication between SP and IdP for attributes, but that's a different problem.)
An SSL/TLS connection wouldn't be sufficient for the IdP to know that the SAML request came from an SP for which it's allowed to authenticate and release attribute, since the connection to the IdP comes from the user's browser, not the SP itself. For this reason, the SP must sign the SAML request message before handing it to the user's browser.
An SSL/TLS connection wouldn't be sufficient for the SP to know the SAML response came from an IdP it trusts. Again, that's why the SAML response itself is also signed.
What applies to signing also applies to encryption, if the middle party, i.e. the user, isn't meant to see what's in the SAML message and/or if the connection between the user and the SP or IdP isn't over SSL/TLS (usually, it should be over HTTPS).
Yes - SSL is enough - but SSL is only point-to-point. You cannot secure your connection using SSL if there are a few intermediaries in the way between your source and your target machine.
In that case, e.g. when transmitting over the internet, you must safeguard the actual message, instead of the transport-level. That's why you need to encrypt the XML (or at least parts of it).
Marc
All that HTTPS will do is encrypt the communication between two points and prevent eavesdroppers -- it won't confirm who it was that sent the message. Neither will it assure secure communication if your message is then forwarded.
If you sign your request with the X.509 certificate you can be assured the decryptor has the shared secret contained in certificate. In other words, you can be assured the message can only be decrypted by the organisation you want it to be decrypted by.
In your case, the X.509 encryption requirement means that you should be assured that the identity provider is the only organisation that will receive your request.
A useful Wikipedia primer is here.
Most likely because they want to authenticate you (the client). HTTPS can be used for client authentication, but it rarely is in practice.
In practice, you could use HTTPS (SSL/TLS) to protect your SAML message. But you would want to use two-way SSL certificate verification/validation, meaning your client would need to verify the server's X.509 certificate and the server would need to be configured to perform client authentication, which would require it to check an X.509 certificate that the client presents. So, the client would need its own certificate anyway.
SSL/TLS is not really designed for this...it was/is designed to protect web traffic from being seen while in transport and for the client to be able to tell what server they are talking to and sending sensitive information to (it was really designed for e-commerce where the client (user buying something) knows who they are sending their credit card information to). In the case of SAML, the whole point is for the parties to know that the information they are exchanging has not been altered in transport and that each is talking to who they think they are. Using certificates to sign/encrypt that message itself accomplishes that.
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).