We are trying to implement a smooth rollover for our saml 2 service provider signing certificates.
We have created new certificates with a notBefore at the date of the rollover in the future. Those certificates are exposed on our metadata endpoint, along the certificates currently used to sign saml messages. They are not yet valid since the notBefore property is in the future. Our service provider will start using them when they become valid.
However some partners are having issues with their identity providers complaining that the new certificate is not yet valid.
So my question is the following: are we allowed to expose future certificates that are not yet valid? If not, how are we supposed to manage the signing certificate rollover in saml 2?
Unfortunately the SAML specification doesn't address how certificate roll over should be handled. Therefore, there's no consistent approach.
What you're doing seems reasonable but then I can also understand why some partners would complain about a certificate that isn't (yet) valid.
Some providers simply update their published SAML metadata at the time of certificate roll over. In other words, the metadata contains the current certificate only rather than any past or future certificates. This then places the onus on the partners to ensure they monitor the metadata and switch the certificate immediately.
Of course, this isn't always practicable. In my experience, it's usually best to communicate with the partners that the certificate will roll over on a certain date and provide them with the new certificate and/or metadata prior to that date. Partners should handle signatures generated by either the new or old certificate for an interval of time around the roll over date to ensure a smooth transition. On the roll over date, you'd also publish the new metadata.
You'd probably want an overlap between the old certificate's NotAfter and the new certificate's NotBefore.
Related
What happens when the signing certificate (used for signing jwt tokens) expires when using IdentityServer 3?
It's unclear to me and I can't find any documentation, other than that it's possible to get a warning that it has expired. (Ref. https://identityserver.github.io/Documentation/docsv2/configuration/events.html)
Is there any mechanism that stops the use of expired signing certs?
And what happens on the client side (client being the Web API that uses IdentityServer for authentication) when validating a token signed by an expired certificate? (For example if https://github.com/IdentityServer/IdentityServer3.AccessTokenValidation is used as a middleware.)
Well I've just tested this (on IdentityServer4) and it seems to continue to work happily with an expired signing certificate, here's my test cert's validity:
I'm able to login, get an ID token and an access token and then access an API with the access token. What IdentityServer does do however is to log a warning:
2017-07-13 12:15:54.871 +02:00 [Warning]
Certificate "CN=test_expired_signing_certificate" has expired on "13/07/2016 14:14:37"
This matches what the IdentityServer (3) docs say here:
IdentityServer raises a number of events at runtime, e.g:
snip...
Expired/invalid/no signing certificate
By default these events are forwarded to the configured log provider - a custom event service can process or forward them in any way suitable for the environment.
So this would be your way of detecting it when it's already too late. A better option is to rollover signing keys periodically and within the validity of the keys, this is the common approach which also allows for a compromised key to be revoked if necessary. See this issue where the process is discussed, basically IdentityServer can handle two keys:
[Middleware refreshes] the metadata document ... once a day.
The metadata doc can hold 2 keys - primary and secondary and the middleware will load and use both when present (JWTs have a key identifier that allows picking the right one).
When you start to rollover - set both keys and at some point swap primary and secondary.
Disclaimer: I never worked with IdentityServer3
The outside world doesn't know your certificate and therefore doesn't know it's expired. The outside world merely sees your public key at:
YourIdentityServer.com/.well-known/openid-configuration
or more accurately:
YourIdentityServer.com/.well-known/openid-configuration/jwks
You can play around with this: Create a new cert on startup (see https://gist.github.com/mykeels/408a26fb9411aff8fb7506f53c77c57a). Even if you set the TimeSpan to one minute, it will keep working.
But once you wait 1 minute and restart your IdentityServer your token from last sign in will be considered invalid, because it was created with the now outdated signing key. It is checked against the new public key and fails.
It seems to be recommended to periodically replace your cert with a new one, while also keeping the previous key around, see "signing key rollover":
https://docs.identityserver.io/en/dev/topics/crypto.html#signing-key-rollover
I'm consuming a soap service from a server that uses ssl certificate. Although I don't have any dependency on the server certificate in my code, but what if the server certificate gets expired? Will the communication between the server and my client be OK?
In general: no, the communication will not be OK.
A certificate is an endorsement, by the issuer, that the requester has met the identity (and other) requirements that the issuer has put in place; and that the public key in the certificate really is associated with the subject.
The expiration date for the certificate exists because the longer ago the verification process was, the more likely it won't hold up anymore. Imagine you bought awesomesauce.example.com, and got a TLS server certificate for it, and the cert had no expiration. After a year you forget to pay your registrar and lose the name. Someone else comes along, buys it, and has a popular website there. You realize that you have a certificate that identifies you as that site, so you sell it for a million BTC to some hacker group who uses it to do various identity theft tricks and ...
This is similar to an expiration on a driver's license. Maybe your eyesight has dropped below the acceptable thresholds and you shouldn't drive. Maybe you moved and the address on the card should no longer be trusted. Slap an expiration date on there and you now have to reaffirm the facts therein.
You can get an idea of how your client will handle expiration by making a request to https://expired.badssl.com/. If it works, you're trusting outdated claims. If it doesn't: be happy about your client doing the right thing.
I'm interested in signing my Silverlight XAP with a self-signed certificate, so it can auto-update. I haven't tried yet, but figure I can create a certificate easily with this question/answer I found on StackOverflow.
But it's not clear to me what the timestamp server does and can I use a timestamp server from a company (for example, the one from Comodo), even if I didn't buy a certificate from them, but self-signed my certificate?
Putting bits and pieces together I found the following answer by BruceCran:
Any timestamp server can be used: I recently switched from my issuer's
timestamp server to Verisign since I found that GlobalSign's server
was unreliable. Furthermore, Thawte don't run their own timestamp
server but recommend people to use Verisign's.
So, yes I assume I can use any timestamp server.
As for what a timestamp server does, it is explained by Comodo:
Since key pairs are based on mathematical relationships that can be
cracked with a great deal of time and effort, it is a well-established
security principle that a digital certificate should expire. Your
Digital ID will expire one year after it is issued. However, most
software is intended to have a lifetime of longer than one year. To
avoid having to resign software every time your certificate expires,
companies have introduced time stamping services. When you sign code,
a hash of your code will be sent to Certification Authority to be time
stamped. Once your software has been time stamped, you will not need
to worry about resigning code when your Digital ID expires. Microsoft
Authenticode allows you to time stamp your signed code so that
signatures will not expire when your certificate does.
So your certificate expires, but your code doesn't.
I have set up a single sign on(SSO) for my services. All the services confirm the identity of the user using the IDPorvider(IDP). In my case I am also the IDP.
In my saml request, I have included the following:
1. the level for which auth. is required.
2. the consumer url
3. the destination service url.
4. Issuer
Then, encrypting this message with the SP's(service provider) private key and then with the IDP's Public key. Then I am sending this request.
The IDP on receiving the request, first decrypts with his own private key and then with SP's public key. In the saml response:
1. destination url
2. Issuer
3. Status of the response
Is this good enough? Please give your suggestions?
In general it goes something like this. There is encryption and then there is singing in SAML. You never want to be in production without digital signature sbeing used for SAML. You can disable signature processing for testing purposes I suppose. We alow this in SiteMinder Federation Servcies (SMFSS) for testing purposes only. So, with that being said you're not saying anything about digital signatures and are only talking about encryption.
But here is a rundown of the two in my own very dumbed down description which although I sound silly with the way I explain it I am hoping it will help you. And if you already know this I apologize in advance. One more thing is that this is very basic but you can get more details on google searching for encrytpion, decryption, certificates, etc.
Actually, here is a rundown of what I use to train new support folks for Federation with SMFSS (SiteMinder Federation Services) and at the end is the section I wrote on certs. This was just something I wrote up very quickly and is not very slick looking but it defintiely gets the job done, and quickly. It was written as sort of a copy of what I do with POC SAML 2.0 POST customers who already have SiteMinder setup. I just figured I would give you this since it has a lot of tools you may find useful once you get going in case you were not aware of them already. ;-)
You will need two environments with Agent, Agent OP, Policy Server, Policy Server OP. Need two agents so one can be IDP and one SP.
To set up Agent Option Pack see:
Chapter 8: Federation Web Services Application Setup & Deploy Federation Web Services as a Web Application & Configure ServletExec to Work with Federation Web Services
Now set up the SAML 2.0 POST authentication: You should use the following as it is step by step. But first see the chapter on settings that must match as they need to match for the IDP and SP sides. The chapters below for IDP and SP set up are pretty much step by step, really, Follow 14 and 16 step by step and you’re good to go.
Chapter 22: Configuration Settings that Must Use the Same Values
Then use this to set up the IDP and SP:
Chapter 14: Configure SiteMinder as a SAML 2.0 Identity Provider
Chapter 16: Configure SiteMinder as a SAML 2.0 Service Provider
Run your SAML 2.0 transaction and get a Fiddler Trace of it. Pull out the certs and create a .cer file. Pull out the assertion and check the XML online using the tools below.
Set up Fiddler Tool and make sure you have HTTPS Decryption enabled. I had the link here but just go to gllgle and type in "Fiddler Tool HTTPS decryption" and you'll get it.
Used to review the URL posted or redirected with SAML transactions taken out of Fiddler Usually:
https://rnd.feide.no/simplesaml/module.php/saml2debug/debug.php
I have used this one multiple times to validate XML (the assertion) when I get parsing errors or other errors with partners saying our assertion is not good or if we have a partners assertion that is not good. I like to check the syntax first and if that is fine then check SAML specs to see if they have correct values in the SAML assertion itself. In other words make sure it is SAML compliant.
http://www.w3schools.com/dom/dom_validate.asp
HINT: You can take the base 64 encoded cert info out of our logs or the Fiddler Traces and paste to a notepad and save it as name.cer. Then when you open this file you can look at the cert the customer is using. This is helpful because then you can see if they have the right cert and see who their Root CA is or their intermediate Root CA. Make sure you get all the data including the = or == that may be at the end of the lines for the cert info.
When performing SLO or Artifact the partner will need to connect on the back channel to a web server on the other partners site. When this happens the Web Server being connected to is being served over SSL/HTTPS. This means that the one connecting to that server must have the ROOT CA cert which signed the web sever’s cert in it’s keystore. The theory of this is the same as when you open a browser and connect to an HTTPS web server. All browsers come with the major Root CA certs already imported into them. The whole point of this is that when you put a cert on a web server it is not really for protection it is to let anyone who connects know that you really are that website and really are who you say you are. The fact that you have a cert makes your site be HTTPS and the reason you believe they are who they say they are is that they give you their cert when you connect and if you have the ROOT CA for that cert on the website then this means you trust their ROOT CA. if you trust their ROOT CA then you can connect. If you do not have the ROOT CA cert imported into your browser then you can not connect over SSL/HTTPS to that webserver.
**Encryption and Decryption (if a packet is reads off the wire then the data is encrypted for safety of packet data):
Encryption is done on the IDP side and you can encrypt the entire assertion, NameID value, Attributes and perhaps more?
Encryption is done on the IDP side using the PUBLIC Key Certificate (SP’s cert) which is given to the IDP offline by the SP.
When the SP gets the assertion (or whatever the IDP encrypted) then it must have it’s private key in it’s keystore so that it can decrypt the data and read it. This is the decryption.
The reason this is secure and protects the data is that ONLY the SP should have their own PRIVATE key. Thus if this packet was stolen no one can decrypt it but them.
***Signing and verification – This is not SECURE as it does not encrypt the data. It is not meant to be secure for the packets it is meant to tell someone you really are who you say you are. So if you sign and assertion your partner will know it came from the IDP they expected it to come from.
The IDP must use their public/private key PAIR to sign the data.
The SP must use the IDP’s PUBLIC key (given to the SP offline) to verify the signature. The reason you know the data is from that IDP is that ONLY data signed with the IDP’s private key and be decrypted with their public key. In other words, you can’t pretend you are that IDP and send signed data to the SP and get them to think it is the IDP because the public key for the IDP can only be used to verify things signed with the matching private key. This proves you are who you say you are.
end silly technote I wrote**
I hope you find the certs info and tools useful in your future SAML endeavours! Happy Federating!
update - I was not able to post all the links but some were just base 64 decryption as it will allow me to post only two I am posting the most needed two.
Thanks!
Crissy Stone
CA Technologies SiteMinder Support
I'm building a solution consisting of an app and a server. Server provides some methods (json) and the app uses them. My aim is to make those API methods inaccessible to other clients. What is the best way to do so?
Should I take a look at certificates (to sign every outgoing request)? If yes, where do I start and what is the performance impact of doing so?
What are alternatives?
Put another way, you need a way to distinguish a valid client's request from an invalid client's request. That means the client needs to present credentials that demonstrate the request comes from a valid source.
SSL certificates are an excellent way to assert identity that can be validated. The validity of an SSL certificate can be confirmed if the certificate contains a valid signature created by another certificate known to be secure, a root cert. As noted in other answers an embedded certificate won't do the job because that certificate can be compromised by dissecting the app. Once it is compromised, you can't accept any requests presenting it, locking out all your users.
Instead of one embedded app cert, you need to issue a separate certificate to each valid user. To do that, you need to set up (or outsource to) a Certificate Authority and issue individual, signed certificates to valid clients. Some of these certificate will be compromised by the user -- either because they were hacked, careless or intentionally trying to defraud your service. You'll need to watch for these stolen certificates, place them on a certificate revocation list (CRL) and refuse service to these compromised certificates. Any web server is able to refuse a connection based on a CRL.
This doesn't solve the security issues, it just moves them out of the app. It is still possible for someone to create what appears to be a valid certificate through social engineering or by stealing your root certificate and manufacturing new signed certificates. (These are problems all PKI providers face.)
There will be a performance hit. How much of a hit depends on the number of requests from the app. The iPhone NSURLConnection class provides support for SSL client certificates and client certificates can be installed in the phone from an e-mail or authenticated web request. Managing the infrastructure to support the client certs will require more effort than coding it into the app.
Incidentally, voting down any answer you don't like creates a chilling effect in the community. You're not nearly as likely to get advice -- good or bad -- if you're going to take a whack at everyone's reputation score.
I will now freely admit that it's an interesting question, but I have no idea how it could be done.
Original answer:
Interesting question. Assuming people can't reverse-engineer the iPhone app, the only solution that comes to mind would be to sign requests with a public key, or some other secret known only to the application. By that, I mean adding an extra argument to every API call that is a hash of the destination URL and other arguments combined with a secret known only to your server and application.
To expand upon this: suppose your API call has arguments foo, bar and qux. I would add a signature argument, the value of which could be something as simple as sorting the other arguments by name, concatenating them with their values, adding a secret, and hashing the lot. Then on the server side, I would do the same thing (excepting the signature argument) and check that the hash matches the one we were given in the request.
Consider authenticated HTTP.
For a cheaper alternative, there's shared secret/hash scheme. The client and the server have a shared secret string of text. Upon request, the client hashes together (using MD5, or SHA1, or SHA something else - you choose) the request fields and the secret. The hash value is attached to the request - say, as another POST field.
The server does the same operation with the request and with its copy of the secret, then compares the hash values. If they don't match - service denied.
For added security, you may encrypt the hash with a RSA public key. The client has the public key, the server keeps the private key. The server decrypts the hash with the private key, then the same. I did that with a C++ WinMobile client and a PHP-based service - works like a charm. No experience with crypto on iPhone, though.
UPDATE: now that I think of it, if we assume that the attacker has complete control over the client (ahem jailbroken iPhone and a debugger), the problem, as formulated above, is not solvable in theory. After all, the attacker might use your bits to access the service. Reverse-engineer the executable, find the relevant functions and call them with desired data. Build some global state, if necessary. Alternatively, they can automate your UI, screen scraper style. Such is the sad state of affairs.