We have an intranet web based information portal. Now, under development is module for internal orders.
The problem is: When the approver approves the order, it accesses page that requires https and accessing it should be much secure than a simple (second) password authentication.
The first idea was to pair certified connection between the server and client, i.e. the server should recognize that client has installed appropriate certificate, otherwise, to show inaccessible page message.
We played with OpenSSL certificates, but because we are newbie in that, there was no success.
Which is the right way to do this?
Probably, this is important: The certificates was done under Linux. They should work on Win2003 server with installed Apache2 with enabled SSL module (PHP, MySQL). Also - pages can be accessed only via IP address of the server. Is it OK to configure certificate for IP address? Information we used to generate certificates is here.
Is there another way to secure connection between client and server in that case, i.e. to ensure that only privileged client (computer, browser) is accessing the secured page? If you have other suggestions, they will be well appriciated.
Related
I have an IS4 install on a regular server on the WWW which is working perfectly for a number of client applications.
The client has a network and I need to install and application inside their local LAN which is not able to be addressable from the WWW.
Is it possible to login to the application inside the LAN via the IS4 instance and have the user return to the site inside the LAN?
Thanks
Jeff
In short, yes. All IDP -> client interactions are done in the front-channel (i.e. in the context of the user's browser). The client app inside the customer's network will need to be able to connect to your IDP but not vice versa.
I am creating a Hotspot network, where I need users to first register in order to get credentials to connect to the internet.
My worry is how does the registration form gets sent to my database which is hosted on AWS putting into consideration that the client who is registering doesn't have Internet yet.
Anyone who has a suggestion on how the process works..?
Thanks
So basically you need to have a route(and a NAT rule) for all unauthorized clients to be able to talk to the endpoint storing/processing the form (i.e. Database).
This way every one can communicate with target and after
authentication they should be provided by a full internet accessible
route.
I have made an app with Spring Boot on backend and UI in AngularJS. UI is separate from the backend. UI is deployed in Firebase and my backend in deployed in AWS (via boxfuse). I want to add a trusted https certificate to my backend but Certificate Manager does not let me create a trusted certificate for Amazon owned domain. How can I add a certificate to the backend (with Let's Encrypt)? Does my UI also need a trusted certificate?
First of all, If you are using public domain of EC2 instance, I would advice not to use because whenever you start and stop instance, It will change the domain. If you are doing with let's encrypt than you should do it in the server which having apache configured. Let's encrypt provide you the ACME client, most recommended is certbot. Choose your OS and Web server. It will provide you the script, Run that script in your server and it will ask for required detail which needed to get SSL Certification. Rest of the things script will do it for you. Please read the documentation before you perform this things.
You should consider the domain type as well either you are using single domain or wildcard according to your application.
Below link is useful for me, If you want you can get more detail about this.
https://www.digitalocean.com/community/tutorials/how-to-install-an-ssl-certificate-from-a-commercial-certificate-authority
CONTEXT
Have created an API using Google Cloud Endpoints (Python) with which numerous low power devices will GET/POST data.
The only communication with the API will be from these custom devices (I own both ends of the communication).
RESEARCH
Looking at authentication, was hoping it would be as simple as using SSL/TLS client certs:
Each remote device will have a client cert signed by a single project CA anyway.
The Google cloud endpoints mandate SSL.
However, only oauth2 appears to be supported; I'm looking for a 'clean' way to implement 'hands off' authentication, ideally utilising the client SSL cert I already have on the client devices.
I have investigated creating 'service' oauth2 accounts, however as I want to protect against a device spoofing another device (one set of credentials for all is not acceptable), I would need to generate a service account for each client device, which would be bulky and horrible to maintain on the API-end.
It seems i'm looming towards needing to add a layer of authentication within my code for each API method, which somewhat defeats the point of utilising the services of Google's cloud endpoints.
QUESTION... Finally
Has anyone had experience in authenticating 'hands off' machine to machine devices at scale against google's cloud endpoint?
Does anyone know of a way of using a client certificate in the Oauth2 authentication process in a way which would be supported by GCE?
Is my only option going to be custom authentication within the API methods based on some crypto data in the POST/GET headers. (or just moving to hosting an API with Apache/NGINX and client-cert auth?)
Regards,
Matt
I wrote you an essay:
Consider that Cloud Endpoints basically exists in the application layer of the OSI model, since it communicates via HTTPS requests (it sends HTTP requests within a TLS session). Whether or not Endpoints uses HTTP or HTTPS is not a developer-configurable option - it must be HTTPS.
It uses HTTPS in that the API server has a TLS cert which is used to authenticate the API server. Inside the secure connection, the RPC params and responses are also secured from eavesdropping. This is the extent to which Endpoints "interacts" with TLS - it uses it to establish the session and send HTTP requests inside this session.
So, already I can tell you that you will not be able to have your TLS client certs (not an often-used feature) used to authenticate API clients automatically by endpoints, in the connection setup phase. TLS client certs simply aren't looked at or requested by the Endpoints API server.
Now, while authentication of the API server itself is guaranteed through the API server's TLS cert, authentication of API clients is done via Client IDs or the Users API, which sits in your code and abstracts over the different auth options App Engine offers at present:
OAuth (2.0)
OpenID
So, in order to auth your client devices in one of these two manners and still take advantage of Cloud Endpoints, you will need to find a way for each device to perform an OAuth flow or OpenID flow, your system having provisioned an identity for the respective auth method at the time of that device's initial deployment.
Google (Apps) Accounts option
This will involve creating a Google account (Google's unified SSO) or a Google Apps account managed by a custom domain for each device, and provisioning these accounts' credentials to each respective device. You can read more about custom domain authentication and App Engine auth configuration in general here.
OpenID option (general doc on OpenID with GAE)
This will involve setting up your own OpenID provider on a GCE instance using an OpenID connect library like pyoidc, so that you can provision accounts yourself, or it could involve registering accounts with a known OpenID provider for each device. The first solution is more robust but more time-consuming (OpenID providers can go down temporarily, or deactivate forever, and then your IOT network is out of luck).
Third option using Client IDs
You can of course generate an "installed application" client ID/secret and distribute these to each device in your network. They can use this to authenticate themselves as network devices (as opposed to an attacker's laptop), and then you trust devices to accurately report their own id as a param with each API call. Depending on how hackable your devices are and how widely you intend to distribute them, this scheme doesn't necessarily prevent devices from spoofing each other's id's, although depending on the id generation scheme, you can make it very difficult (each id being a long sufficiently long hash).
If you go this route and you're really concerned about this, you can provision a client ID for each device, but who knows if you'll hit some kind of undocumented limit on number of client IDs per app, and also this will require you to either do it by hand or write a script that logs into the dev console on a headless browser and does what you need.
Fourth crazy option that actually uses the TLS client certs
If you're really set on using both TLS client certs for auth and Cloud Endpoints for your API, you could try to send the client cert in the request, since TLS is encrypting the request data (unless your attacker has found a way to efficiently solve the inverse discrete logarithm problem, in which case they'll probably be too busy attacking more important targets (no offense) and changing the infosec game forever), and then reading and auth'ing the cert in your endpoints method somehow (third party libs uploaded with your app are probably necessary for this).
Fourth realistic option if you have your heart set on TLS client certs
Switch from App Engine to Compute Engine, where you basically have a VM managed and hosted in the same data-centers. On this box, you can implement any kind of connection protocol on any port you like, so you could have incoming API requests (not Endpoints, notice) TLS-authenticated based on teh connecting device's client certs.
Good luck!
I need to invoke a REST-based service from Windows Phone 7.
The service only accepts the request if the following conditions are satisfied:
The request must happen over HTTPS/SSL
The request must be authenticated with a client X509 certificate
I don't control the service, so I can't change the authentication requirements.
On the full framework, we can do things like this:
HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create(uri);
request.ClientCertificates.Add(accessCertificate);
However, the ClientCertificates property isn't available in Silverlight 4, and neither do any of the X509 classes from the System.Security.Cryptography.X509Certificates namespace seem to be available.
Is it really impossible to make Client Certificate-based HTTPS requests from Windows Phone 7?
Client certificates are not supported by the 3rd party WP7 SDK currently.
Confirmation here for your reference.
Problems with client certification authentication on WP7
Whilst it's possible to install certs on the device through email (referenced in an exhcange integration solution), your app won't use them.
There are only 2 ways to install 3rd party certificates on the device and neither can currently be done through code:
Installing certificates via Windows®
Internet Explorer®
A certificate can
be posted on a website and made
available to users through a
device-accessible URL that they can
use to download the certificate. When
a user accesses the page and taps the
certificate, it opens on the device.
The user can inspect the certificate,
and if they choose to continue the
certificate is installed on the
device.
Installing certificates via email
The certificate installer on
Windows Phone 7 supports .cer, .p7b,
and .pfx files. When installing
certificates via email, make sure your
mail filters do not block .cer files.
Certificates that are sent via email
appear as message attachments. When a
certificate is received, a user can
tap to review the contents and then
tap to install the certificate.
Typically, when an identity
certificate is installed the user is
prompted for the passphrase that
protects it.
You'll have to get the user to perform one of these actions before the app will work with the certificate.
From Windows Phone 7 and Certificates_FINAL_121610.pdf
So you can us oAuth for authentication and pass the token in the request header. If you check out acs.codeplex.com you can see how this is done using the Azure ACS system. I realize you may not be using Azure, but the reference app may help. I would also search for oAuth and Windows Phone 7, I have found a few examples that way too.
As far as SSL, you should be able to do that through the browser with out any issue. You can also open any https Url using an HttpWebRequest, etc.