I have been given an assignment for User registration and login using Spring boot. Front end I have used thymeleaf.I have developed the application in my localhost.
Below are the deliverable
Deliverables
● Source code ---- Done with GitHub
● Public working url of the webapp --- How to do???
● Tests - unit and integration tests. you may also choose to use a ci ---- Done
I would like to know how to create a public working URL for a project developed on localhost.
This process is called deployment. You may use Heroku, just follow the instructions. At the end, you will get an URL like http://my-lovely-app.herokuapp.com/ which is public and working.
Just go to the command line and navigate to your program by typing “cd (the path to your web app)”. Then in the command line type “gcloud app deploy”. Then click on the link to your site.
to answer this question, one needs first to understand an overview of an http(s) request lifecycle:
user enters an URL in his browser: https://some.domain:8080/request/path?param1=value1¶m2=value2
the browser splits the URL into protocol scheme ("https"), server DNS name ("some.domain"), port (8080), request path ("/request/path") and query-string ("param1=value1¶m2=value2"). If a port is omitted, the default port for the given protocol is assumed (80 for HTTP, 443 for HTTPS, etc)
the browser performs a DNS lookup to translate server DNS name to an IP address.
the browser makes a TCP connection to server's IP address (in theory HTTP can also use UDP, but it is rarely used, so we will skip this case)
if HTTPS was used, the browser and the server perform TLS handshake during which, among others, they exchange and verify each other's SSL/TLS certificate chains (usually it's only server presenting its certs and the browser verifying them, but you can also install client certificate and a key in your browser)
the browser sends the HTTP request over TLS (in case of HTTPS) or over bare TCP (in case of HTTP) to the server.
the server running software appropriate to execute your app routes the request to it to obtain a response that it will send back to the browser.
Points 1, 2 and 6 do not require any setup from you side.
For point 3 to work, you need to have a proper DNS record on some public DNS server.
For point 4 to work, your server needs to have a public IP address assigned by an ISP.
For point 5 to work, your server needs to have installed a valid SSL/TLS certificate issued by some certificate authority (you can skip it if you need only HTTP)
For point 7 to work, your server needs to have appropriate software and your app installed similarly as your local dev machine.
There are a lot of services available that provide all 3 or some subset of them for you, some of them even for free up to some capacity.
Let's start with a server and an IP address:
the most hardcore and low-level approach is to buy a public IP from your ISP and host your app on your local machine. this is not recommended however because of availability issues: whenever there is any network or power outage or if you turn off your machine, your app will be down. other solutions provide much better level of service (they have redundant power sources, internet connections and staff making sure that everything works 24/7)
a bit higher level approach is to buy a virtual or dedicated server from some hosting company (search the web for "VPS", "dedicates server" or "VM hosting" to find one in your area. Well know global ones are for example Google Cloud Compute Engine, AWS EC2, M$ Azure, OVH). These companies will provide for you a server with a public IP, full administrative access (via SSH usually) and some guarantees on it's availability (usually ranging from 99% to 99.99% -> the more 9s the more expensive it is). After that you will need to install and configure all necessary software to run your app on such server. These companies often offer DNS entry in their subdomain and an HTTPS ceritficate in a package for a small to even zero fee. Many of them also offer packages containing a separate domain of your choice and sometimes a certificate.
the most high level solution is a cloud app service (like mentioned in the other answer Heroku, AWS Beanstalk, Google App Engine, kubernetes cluster etc). These services will provide a configurable size pool of instances hosting your app with some load balancing in front of them. This will make your app easy to scale and have a very high availability rate. This is the best solution in most cases: just make sure that the given service provider supports technology stack required by your app. Again, companies providing such services often have packages with DNS entries and HTTPS certificates.
If you need to buy a DNS domain separately (you didn't like any of the packages offered by the server provider) just search for "DNS names" or "domain names" and you will find a lot of resellers. These resellers will provide you a console where you can bind IP address of your server to the DNS name.
Finally if you need to obtain SSL/TLS certificate, you can also search for providers on the web or you can use free automatic certs from https://letsencrypt.org/
That's pretty much it.
Related
I followed this article to create a java program for testing kerberos authentication: https://docs.oracle.com/javase/jndi/tutorial/ldap/security/gssapi.html
The only thing I changed were the configuration files.
The program works fine when I point the DNS settings of my windows client to my internal windows DNS/Kerb server but it times out when I use a separate public DNS server, even though:
1. My internal server has ports tcp/udp 88 open
2. My external server has the SRV records needed (_kerberos._tcp and _kerberos._udp on port 88)
3. I'm able to achieve kerberos authentication, with and without a user certificate, using my iPad which is not using my windows server's DNS
Both the iPad and my other clients are using the same network (my home wifi) and I've also tried by sharing out the data connection from my cell phone.
Given #3 above and the fact that the java program works from a client that uses my internal DNS, I'm a bit baffled as to why my java program wouldn't work in both scenarios (i.e. using the internal or external DNS server).
Do you have any suggestions?
From GitBook Hadoop and Kerberos: The Madness Beyond the Gate section Error Messages to Fear
Switching Kerberos to use TCP rather than UDP makes [some bizarre
issues] go away ... Note also UDP is a lot slower to time out ...
Kerberos waits ~90 seconds before timing out, which is a long time to
notice there's a problem ...
In /etc/krb5.conf
[libdefaults]
udp_preference_limit = 1
PS: the "~90 seconds before timing out" may refer specifically to the Java-specific defaults i.e.
kdc_timeout = 30000
max_retries = 3
Generally speaking, UDP seems to be a root cause for many weird Kerberos issues, cf. How to save Kerberos Service Ticket using a Windows Java client? for instance.
Disabling it systematically might be a "good practise".
I am having doubts about how to secure my microservices application with SSL.
A quik situation sketch :
I have a amazon ec2 instance with a loadbalancer in front.
On the ec2 instance I am running 5 microservices with a registry and a gateway application ( in a VPC ).
The loadbalancer uses a certificate from the Amazon certificate manager.
I also have a self signed certificate generated with the keytool.
Now the question I am having is :
Should I only configure the self signed certificate for my gateway application and register the self signed certificate with the loadbalancer as a trusted certificate or should I configure the self signed certificate for every microservice also ?
Regards,
You want to have microservices exposed to end user, and secured with https.
If you want security, please don't use self signed certificates. Let's Encrypt is much better option.
You can use API Gateway for that, it goes with https. It may be single endpoint for your all services - then directories can lead to different services. On the other hand, if all that goes on single machine, I would use single JVM... But that is different story.
Other option is more unclear. According to comments - not only for me. If your microservices are exposed to internet - you can terminate https on your load balancers. What I don't get is that >>my gateway application<<. It looks like there is something in between end user, and microservices... If that is true then https should be terminates somewhere there.
As a side note - I have no idea why you have load balancer in front of EC2 instance. Usually LB is used in front of auto scaling group to spread load among it's instances. If you want to automate that - Elastic Beanstalk is good option.
I have a Spring application inside a tomcat 8 container, this application has both local (intranet) and remote (internet) service. I would like to serve local services with simple HTTP and remote with HTTPS, is it possibile editing tomcat configuration and without filter requests inside the application?
I should distinguish local from remote requests by its ip address.
You shouldn't need to. Your local network should be protected by a firewall, and you simply configure the firewall to only allow the secure port through.
Local traffic from the intranet doesn't go through the firewall, so it can access the HTTP port (80, 8080, ...).
External traffic comes in through the firewall, and it will block the HTTP port and allow the HTTPS port (443, 8443, ...).
Often with HTTPS, you don't even let Tomcat handle that, but instead put IIS (Windows) or Apache (Linux) in front of it. In that case you only have an AJP connector on localhost, and nobody can talk directly to Tomcat. The frontend web server will then do the required filtering and SSL/TLS handshake.
If you have anything that's worth using https for, I'd opt to go https all the way: Otherwise you'll sooner or later have information leaks because you've missed some crucial part of configuration. HTTPS is no black magic anymore, performance impact is low if exists it at all.
In fact, the typical usecase that I see described is exactly opposite to yours: Intranet usage is typically more protected than internet access (which is thought to be anonymous, but it depends on the nature of the site). However, an Intranet is typically authenticated (more so than the internet side, typically) and I'd expect it to be quite important to protect the authentication. The only mixed-mode solution (http/https) that I could come up with for this situation is: Use HSTS as soon as a user logs in, don't bother otherwise.
You're asking for the opposite of what I typically see - but my actually preferred solution (in all cases) is: Force https everywhere, use HSTS. And don't worry any more. Easier to maintain, Easier to setup and hard to get wrong.
I'm wondering if there is a way to setup connection between a client and a server over the internet and have both of them programmatic setup all needed router/firewall configuration changes to open needed external ports to communicate.
Assuming both server and client have known ip addresses and a DNS is not needed in this example to find the IP addresses. How might one have a server that when started configures access past the firewall and tells the router how to route proper communication to the server. I would assume the client may not need anything like this as it should only need to know the external IP address and port number of the server. If i'm wrong about my assumption please let me know.
Example if I have two houses house (A) has a server and house (B) has a client and both sites know what the other house external IP address is and know what port they will be using how may a Java application do all the configuration or at least do as much as possible on say windows,mac,ubuntu. The idea is the user of the server and client should not have to do a bunch of firewall/router configurations to get the application running. It would also be nice if in the example it shows how to release the connections when the server is terminated. Example when the java server is turned off it should close up port settings on the firewall and router. security and clean house.
There is no easy way of doing that as it will depend on the OS and on the many possible firewall application running on the machine. Plus, if your app crash, you will never set back the original parameters, which can be problematic when talking about security. Instead of trying to set up custom configuration, you should try to use standard communication template/protocol like http. This will gives you a high probability of your app running without additional configuration almost anywhere (since there is almost no point of having an internet connection if you don't allow http port).
Currently I have got a specific problem finding a solution and I am hoping you are able to provide
some light on the matter.
The Structure of the problem:
The task at hand is to gather a client's login credentials (token) and pass this to the servlet. However I cannot seem to find a good resource to do this. I have researched a wide variety of ways. I.e SPNEGO, WAFFLE etc..., However, these seem to require some sort of active directory by my understanding, I am trying to gather the credentials from the users local machine. A clear explanation or guidance to how I can gather the windows credentials to the servlet for my specific request would be appreciated.
Diagrams are always a better way of explaining so I will provide one if you are still confused:
Windows PC (Client) ------------------------> Java Servlet -------------------------------------> IIS Server
(windows authentication) --------------> (Get Credentials) -------------------- (Check Credentials & Authenticate)
(token) (pass credentials)
Thank you in advanced to anyone who replies, I really appreciate it!.
You are wasting your time. If you only take the credentials from the users local machine then you have no way of knowing if those credentials can be trusted. You might as well just give every user administrative access to your web application.
The reason active directory (or something like it) is required is that it is not under the control of the client and is trusted by the server. For example, when using SPNEGO, the client authenticates itself to the windows domain, the client gets a token from the windows domain that it can only get if it is authenticated, the client passes the token to the server, the server can then validate that token with the Windows domain to confirm that the client is indeed who they claim to be. (Not quite that simple but you get the idea.)
There are other ways to do this - e.g. with PKI - but they all have in common a central, trusted authentication system that the server can use to validate credentials provided by the client.