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.
Related
Hopefully I can make this clear enough.
Goal:
Client Certificate-Authenticated Azure Function
Scenario:
Azure Function App with:
HTTPS Only: set to Yes
Client certificate mode: set to Require
HTTP-triggered Azure Function (Python) which:
Loads client certificate from X-ARR-ClientCert header
Pulls a pre-shared client cert from a database and compares:
Issuer
CommonName
Not Valid Before/After
Hits the listed OCSP endpoint to see if cert is revoked
If properties from each cert match and the certificate has not been revoked, the Function will generate a SAS token for the requestor and send it in the response.
Question:
How is the cryptographic part of client cert auth handled in this scenario?
According to this (great) blog post, there is a CertificateVerify step where...
"The client is authenticated by using its private key to sign a
hash of all the messages up to this point. The recipient verifies
the signature using the public key of the signer, thus ensuring it
was signed with the client’s private key."
I don't see a way to access ...all the messages up to this point. to validate this has occured using the Function (Python) code.
Is this something Microsoft handles automagically (similar to how they forward client certs via the X-ARR-ClientCert header)? Or is this not possible?
From what I implemented in a similar case:
Your app received the certificate via the header and must:
load the certificate (using the library cryptography in python for example)
verify the signature of the certificate with you certificate authority
verify the date of validity
verify that it has not been revoked
Using web app (but the same would apply to functions), the Azure frontend seems to just launch authentication protocol to verify that the client that send the certificate has the private key associated (and launch the mutual auth protocol as described in the blog post). But it does not verify the validity or signature of the certificate.
The CertificateVerify step you're mentionning seems to be handled by the Azure Frontend, I don't think your need to worry about this process.
Hopes this helps !
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.
So, right now I'm building an API for third parties uses and I was reading about RS256 and HS256. What I understood was that diff between is that in the first one you use a public key to verify and a private key to sign, and the other one, use just one key.. So if you use RS256 if because you want to keep your secret key secure and want the client to verify the token, but what I don't understand why you would like to verify the token in the client? Because you do a post request to the server, then it sends you back a token and whenever you want to make an authorized request you just use that token and the server verifies it and let you continue if its ok. So, why you would like to verify the token in the client? I thought it was a backend's duty.
I think maybe I'm wrong in something, hope you help clear this. Thanks.
EDIT:
So, my question is, I know the differences between RS256 and HS256 but what I don't understand it's the flow of how is use it. Right now I'm developing a third party api, and I just need to return a token when the client ask for it and then in the request that needs it, just verify from the server if it's a valid token. From what I understand, RS256 it's used when you want to verify your token from the client, if that's right, someone can give me an example of when or why would you want to verify the token in the client?
Use RS256 when:
tokens are signed by a third party, usually an Identity Provider(e.g. oauth2/oidc), and you need to verify that the token has been issued by a trusted entity
tokens are signed by clients, usually to get access to an API, where clients have previously registered the public key
tokens are signed by a centralized authentication server in a SingleSignOn system and they are used to get access to several federated servers
tokens are used to transfer data between two parties, not neccesarily for authentication purposes, and the signature is used to ensure the identity of the signatory
Use HS256 when:
tokens are signed and validated by the same server
I am implementing an app where I don't have a system requiring username and password. What I do require is a name and a phone number.
The scenario is like this:
1) user opens the app for the first time
2)app makes a request to my server and gets a unique UserKey
3)from now one any request the app makes to my REST service also has a signature. The signature is actually a SHA(UserKey:the data provided in the request Base64Encoded)
4)The server also performs the same hash to check the signature
Why I don't use SSH:
not willing to pay for the certificate
I don't need to send sensitive data like passwords, so I don't see the benefit of using it
I just need a simple way to call my own WCF REST services from own app
I understand that there is a flow of security at step2 when the UserKey comes in cleartext, but this happens only once when the app is first opened. How dangerous do you think this is?
What would you recommend? Is there any .NET library that could help me?
Actually, there are several problems with that approach. Suppose there's man-in-the-middle whenever you make a request to the server. By analyzing, for example, 100 sent packets he would recognize similar pattern with signature in your requests. Then he would forge his own request and add your signature. The server checks the hash - everything's alright, it's you and your unique user key. But it's not.
There's a notion of asymmetric keys in cryptography which currently is really popular and provides tough security service. Main concept is the following: server generates two keys - public and private; public key is used to encode texts; they can be decoded only with the use of private key, which is kept by the server in secure location. So server gives client the public key to encode his messages. It may be made double: client generates public key and gives it to the server. Then server generates keys and gives encoded with client's public key his own public key. This way it's almost impossible for man-in-the-middle to make an attack.
Better yet, since the problem is really common, you could use OAuth to authorize users on your website. It is secure, widely used (facebook, g+, twitter, you name them) and has implementations already in variety of languages.
Since you control both the application itself and the webservices, you can do this with SSL (which gets rid of the problems with your current approach) without paying for anything. You can create a self-signed certificate and install that on your webserver; configure the SSL context of your client application to only trust that one certificate. Then, create a client-side self-signed certificate and install that within your application. Set the server up to require mutually-authenticated SSL and only allow your self-signed certificate for access.
Done. You client will only talk to your legitimate server (so no one can spoof your server and trick the client in to talking to it) and your server will only talk to your legitimate clients (so no one can steal information, ID, etc). And it's all protected with the strong cryptography used within SSL.
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.