So I am setting up an SSO implementation FROM my website TO another site. I understand how to build the requests and sign them and all of that stuff. What I am having trouble understanding is the certificates. Who gets what certificate, to be specific. I know how to generate them, but I am not sure if I send over the certificate to the website I am signing into or if they have to generate the certificate and keystore and send us the certificate. There is a little confusion in this part of the process for me that I could use a little help in clarifying.
Since I am accessing their site, it would seem to me that they should generate the certificate and send it to us, and keep the keystore on their machine for the handshake. If I have to generate both, where is the keystore typically kept? We have a couple implementations of this on our site, but the developer that wrote them no longer works here and there is little to no documentation left behind. Also, is the certificate a self-signed certificate that can be used in production? I believe it is, but just want to be sure. Any help in clarification would be greatly appreciated.
It's public key infrastructure (PKI) so you each get the other's public key certificate. It's normally done using the SAML2 metadata profile so you can have their public key certificate.
Looks like you're an IdP if they want the attributes encrypted you need to use their public key to do that. You sign your SAMLResponse to them with your private key and they validate it with your public key. So you each generate your own keys and keep them secret as they are secret keys for signing. You exchange public keys.
You need a certificate for your login endpoint but the other party don't need to see this. They only need your public key certificate for use with the XML exchange and you need their certificate to validate the signature on the SAMLResponse (if you're an SP).
The certificate for working with the SAML XML is normally 10 year self signed.
Related
I have an iPhone app that is using my php api on the server but it is currently open if someone knows the url. I want to make sure that no one can use this API until I am ready to make it a public api (if I even do)
I have read this article but I am unsure what they mean when they say:
[CLIENT] Before making the REST API call, combine a bunch of unique data together (this is typically all the parameters and values you intend on sending, it is the “data” argument in the code snippets on AWS’s site)
I don't understand how if I hash the parameters I plan on sending with my api secret how this is more secure than just hashing the api secret if I send the parameters/values unencrypted.
HTTPS the API and use an API key. Then you'll know that only people (you in this case) with the key can have access to the API.
You're correct about it not being more secure. That's why I suggest you SSL the connection. Unless you plan on encrypting everything you transmit back and forth.
The public/private key scenario will also work well. HTTPS requires very minimal effort.
Digital signatures provide a way of validating a message sent over an insecure connection.
Setup: each client will have its own private key and public key (only the private key needs to be stored on the client). The server will store the public keys for each client. The public key can be visible to all and can be used by the server to identify the client. The private key, known only to the client, it is never shown to anyone.
The client signs the request: along with the rest of the request data, the client will hash the combined request data and encrypt the hash with the private key. The server will generate the hash the same way (leaving the signature out of the hash calculation), then decrypt the signature using the public key. If the hashes match, the request is authentic.
Note that HTTPS allows for client certificates, so you can leverage existing tools to accomplish all of the above without writing a single line of server-side code (you just have to configure your web server; the only trick is to make sure the server only accepts certificates it already has). Moreover, the amount of client side code should be minimal: you shouldn't need to do much more than set the connection to use the client certificate. Since you're controlling the clients, you can use self-signed certificates and add the server as a certificate authority. There are a number of questions on SO about using client certificates in iPhone apps; you can start by reading through them.
Note also that any scheme to protect the web API only works so long as copies of the app are in trusted hands. Should anyone untrustworthy get ahold of it, they can use the app or extract any secret data used by the app and access the API as they will.
For development purposes you can just use your web server settings to allow requests from your ip only.
I'm not very used to oAuth or using SSL certificates and was just recently forced to look into it for put.io API access. oAuth seems complicated, some methods ever require the end user to fill out their credientials.
So I went to search for a ready made PHP lib that has the full put.io API implemented and noticed he used a method where not even the "application secret" or "client ID" was needed.
All I had to do was feed it my "Oauth Token" value and it connected with ssl vertifypeer and a cafile - StarFieldSecureCertificationAuthority.crt
Now the question I guess is what this certificate really does or proves, and if I can really use his - or if this is something I should generate myself for the target deployment server?
Suprisingly, Google didn't help much at all - and I have still no idea how this oAuth with a certificate works, why it works, and how I can make sure that it does work. Any pointers?
Presumption
I take it this is the "ready made PHP lib" you refer to? If you have a question on what some code does with some file, it's helpful to post a link to the code and even more helpful to post your breakdown of it. If you try to read the code, you'll get better Google terms, and clearer narrower more easily answered SO questions, that have a wider application for other future visitors: A question "What does some code do" is easier to answer and may be found by people in the future that search for the same function.
SSL certificates
It's hard to understand what some API code does with a certificate if we have no understanding of what certificates are for. So lets try to get ssl explained to us. If reading the explaining answer on security.stackexchange.com comes hard to you, youtube is the dyslexics best friend.
So now we know that certificates are used to confirm identity or, in other words, for authentication.
OAuth tokens
OAuth tokens are like car keys; a secret that grants access to a car. In your case the car is put.io (the Resource Server). Some cars have separate keys for starting it, opening the trunk and opening the glove compartment. Some tokens only grant access to some of all the Owners Resources.
Basic idea is here, that we shouldn't leave carkeys left in our care out in the open and we shouldn't stick them in just any car we see. Because it's pretty easy to make a device that looks like a car and reacts like a car, but in fact is a car key copier. Trust me, it's the next big thing after credit card skimming. So we need to confirm the identity of the car, before stick our keys in. We need to authenticate the car.
It's pretty easy to make a device that looks like put.io and reacts like put.io, but in fact is a man-in-the-middle that copies tokens. So we need to authenticate put.io before we send the precious token.
Authenticating put.io
That is where the SSL certificates come in. Without repeating what we learned from the SSL section, we know we should carefully check the authenticity of the server certificate we get from, what we believe is, put.io. We need to check if the signature on that certificate comes from an authority (a CA) we trust. To do that we need the certificate of the CA. Many operating systems and browsers come pre-packed with trusted CA certificates.
Just open https://put.io in your browser and look for the certificate. Often by (right) clicking some padlock icon and some click for more information. You'll see that it is issued by 'Starfield Technologies, Inc.'
Using StarFieldSecureCertificationAuthority.crt
Now in NativeEngine.php we see:
$context = stream_context_create($contextOptions);
The ssl options require either a cafile or a capath. The easiest way for the API maintainer to be cross-platform is supplying a cafile. OS package maintainers will likely patch this and exchange it with the capath to the CA files they supply in their OS.
Can you trust it?
Now if the API maintainer has created that crt himself, he can impersonate any server if you use it. Luckily, you can easily check the fingerprint and see if it corresponds with the one in your browser. You can export the one in your browser if it doesn't.
The OAuth token is what authenticates you against the put.io API. (As you can see in this example, where no additional CA certificate is used.)
The CA certificate and the VerifyPeer setting are there to protect the integrity of the connection between your application and put.io: The library uses it to verify that the server it connected to really is put.io's, before proceeding to submit the OAuth token. Your code should also work if you disable the verification; but then your application would be vulnerable to a MITM attack and an attacker could obtain your OAuth token – and would then have access to your put.io account. (The same technique is used in HTTPS. See this question at ISSE for further details on the verification process.)
Note that your solution works for now, but the put.io API documentation states that they might start to expire OAuth tokens in the future, so in the long term you should switch to a library which is able to obtain new tokens (there's a list in this question):
Although at this time we do not expire OAuth access tokens, you should be prepared for this possibility in the future. Also remember that a user may revoke access via the put.io settings page at any time. Using /authorize will ask the user to re-authenticate their identity and reauthorize your app while giving the user the option to login under a different account.
I have an iPhone app that is using my php api on the server but it is currently open if someone knows the url. I want to make sure that no one can use this API until I am ready to make it a public api (if I even do)
I have read this article but I am unsure what they mean when they say:
[CLIENT] Before making the REST API call, combine a bunch of unique data together (this is typically all the parameters and values you intend on sending, it is the “data” argument in the code snippets on AWS’s site)
I don't understand how if I hash the parameters I plan on sending with my api secret how this is more secure than just hashing the api secret if I send the parameters/values unencrypted.
HTTPS the API and use an API key. Then you'll know that only people (you in this case) with the key can have access to the API.
You're correct about it not being more secure. That's why I suggest you SSL the connection. Unless you plan on encrypting everything you transmit back and forth.
The public/private key scenario will also work well. HTTPS requires very minimal effort.
Digital signatures provide a way of validating a message sent over an insecure connection.
Setup: each client will have its own private key and public key (only the private key needs to be stored on the client). The server will store the public keys for each client. The public key can be visible to all and can be used by the server to identify the client. The private key, known only to the client, it is never shown to anyone.
The client signs the request: along with the rest of the request data, the client will hash the combined request data and encrypt the hash with the private key. The server will generate the hash the same way (leaving the signature out of the hash calculation), then decrypt the signature using the public key. If the hashes match, the request is authentic.
Note that HTTPS allows for client certificates, so you can leverage existing tools to accomplish all of the above without writing a single line of server-side code (you just have to configure your web server; the only trick is to make sure the server only accepts certificates it already has). Moreover, the amount of client side code should be minimal: you shouldn't need to do much more than set the connection to use the client certificate. Since you're controlling the clients, you can use self-signed certificates and add the server as a certificate authority. There are a number of questions on SO about using client certificates in iPhone apps; you can start by reading through them.
Note also that any scheme to protect the web API only works so long as copies of the app are in trusted hands. Should anyone untrustworthy get ahold of it, they can use the app or extract any secret data used by the app and access the API as they will.
For development purposes you can just use your web server settings to allow requests from your ip only.
I have Php based Application. which works perfect with login and password. Now i want to implement authenticate using OpenSSL along with login and password.
I have generated the OpenSSL in Linux server and i have to use the generated openSSL.cert file as certificated. I installed that in my browser and my DNS is set with https so it should promte for certificate,
Now what i need is, When somebody tries to login wihtout certificate it should not now allow to login. I should check the certificated to authenticate the login.
Is they any way to do this or am i being more ambitious ?
if yes, How can i do this i php ?
Thanks all.
SSL uses Diffie-Hellman (or similar) key exchange to negotiate a connection meaning that the certificate is provided to any client that does not already have it. What you want to do is probably best done by using a license key file. Were I doing it I should create a hashed key using something company specific that only I knew and have the string passed across to authenticate. The benefit of it over preventing key exchange in SSL and sending out certificates is that the hashed string is easier to create on a per client basis. This means that you can uniquely identify a client easily and give specific limitation, such as an expiry time, by client.
Have found the following example of OAuth server
http://oauth.googlecode.com/svn/code/php/OAuth_TestServer.php
But it is unclear for me
1. How I should generate certificates
How I should specify access token/access token secret/request token/request token secret,
should they stored in database? Should it regenerated for each request? What else I should store in database?
Where should I implement the verification of Access token?
Please advice
To Generate Certificates, you need to create a CSR (Certificate Signing Request)
If you have access to cPanel, then you can generate a CSR easily. If you don't then you will need to download some software to generate a CSR.
After you have your CSR, you can head over to CACert for a free certificate. However, be warned: not all modern browsers trust CACert, so you might get warnings. If you don't want this, you will have to pay for a certificate from a professional provider, like VeriSign.