Tomcat with HTTPS REST Setup - rest

I'm writing a REST server using Jersey for Tomcat. I'm proficient in Java but this is my first time writing for web, so I hope this question isn't dumb. I've tried searching all over but can't come up with an answer I understand well.
I'm trying to utilize HTTPS and basic auth, but I don't know if I have to write anything in the actual Java to accomplish this. Does Tomcat take care of all encryption/decryption of SSL info, or do I have to do something in my server code to take care of this? In the client I know I will have do this manually, but I can't find anything about how to do this on the server end. Is it a Tomcat setting? Do I have to set Tomcat to only forward HTTPS traffic to my server, and then it will decrypt and send the decrypted information to my server, where it will act just as though it was a regular unencrypted command?

For the server, you first need to make sure Tomcat is configured to support HTTPS/SSL/TLS. This includes setting up the keystore and editing a configuration file. You can see all the details of how to do that at SSL/TLS Configuration HOW-TO. Note that link is for Tomcat 8. For Tomcat 7, you should search for the according docs.
Once you have that set up, all there is left to do to actually make use the HTTPS, is to set the <transport> to CONFIDENTIAL in the web.xml file of your web application.
<security-constraint>
...
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
If you have never set up the web.xml seucurity yet, then you'll want take time to read Securing Web Applications. There is also a section on setting up Basic auth with web.xml configuration.
When you get the section about Basic auth, you will notice a configuration of <realm-name>. The realm is something that needs to be set up with Tomcat. This is basically the access point to the store of users that Tomcat will lookup the authenticate. To read more about setting up a realm, see Realm Configuration HOW-TO (again this is a Tomcat 8 link). There different types of realms to choose from, so just pick one, like the JDBC realm.
And that's it. Rather than give a tutorial, I think the links I provided are goods officials sources that will do a better job at explaining than I could do. If this is all new to you, it might take you a day to set everything up, but I'm sure you will learn a lot from those documentations.
Another thing, if you want to do authorization, once you set up the realm in tomcat with roles (see example in JDBC realm section), you can either use the roles authorization configuration in the web.xml (see "Securing Web Applications" link) or you can use Jersey's role based authorization, which will give a little more fine control. For that see Authorization - securing resources

Related

yii2 remove backend/web and frontend/web from url

I am trying to change site url from http://localhost/yiiwebsite/backend/web/index.php url to http://localhost/yiiwebsite/admin and http://localhost/yiiwebsite/frontend/web/index.php url to http://localhost/yiiwebsite/.
Can anyone help me to do this.
It's described in official docs here.
Here is some basic info:
The application installed according to the above instructions should
work out of box with either an Apache HTTP server or an Nginx HTTP
server, on Windows, Mac OS X, or Linux running PHP 5.4 or higher. Yii
2.0 is also compatible with facebook's HHVM. However, there are some edge cases where HHVM behaves different than native PHP, so you have
to take some extra care when using HHVM.
On a production server, you may want to configure your Web server so
that the application can be accessed via the URL
http://www.example.com/index.php instead of
http://www.example.com/basic/web/index.php. Such configuration
requires pointing the document root of your Web server to the
basic/web folder. You may also want to hide index.php from the URL, as
described in the Routing and URL Creation section. In this subsection,
you'll learn how to configure your Apache or Nginx server to achieve
these goals.
By setting basic/web as the document root, you also prevent end users
from accessing your private application code and sensitive data files
that are stored in the sibling directories of basic/web. Denying
access to those other folders is a security improvement.
If your application will run in a shared hosting environment where you
do not have permission to modify its Web server configuration, you may
still adjust the structure of your application for better security.
Further configuration depends on chosen web server (Nginx / Apache), which is not even mentioned in the questoin. But both options are covered in official docs by the given link.
For shared hosting environment there is special section too.
And by the way this was asked before many times here on SO, just do a better research.

Jboss EAP 6 : HttpRequest http-header validation

As a security measure my organization requires me to validate a header attribute to allow a request to go through the business rules. Where would I need to configure this in the Jboss eap 6.3? This configuration was done before me and i am not sure how it was achieved before in the earlier jboss 5.x. Please let me know how would I configure the container security without making any application changes.
You could do this in a Global Valve, which is like a servlet filter but with more access to JBossWeb (Tomcat) internals and applies to all requests. Details are in the documentation at https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.4/html/Administration_and_Configuration_Guide/chap-Global_Valves.html
That is not portable between containers, and will not work in WildFly or EAP 7+ since the web container has changed from JBossWeb to Undertow.
In my understanding, this has to be done in applications. Not sure if this can be done generally in JBoss configuration.
Try this https://www.owasp.org/index.php/How_to_add_validation_logic_to_HttpServletRequest
Turns out we had a different way of handling it. We used the single sign on feature of Jboss 5 and at the container level validated the header. When the header was validated, a generic role name was exposed which was used by Applications to limit the resources to the specific role name.

Right design for SiteMinder

I have to give my recommendations for an architecture for SSO using Site Minder.
We have few J2EE applications. These J2EE applications are designed to work when http headers have information after authentication by SSO provider. We have kept our applications SSO provider agnostic. This means we only rely on headers from SSO provider. This worked well with RSA as the SSO provider.
Now there is another architecture proposed with SiteMinder. The way request will flow is
SiteMinder with IIS -> Apache Reverse Proxy -> Tomcat Application -> Backend Applications.
To break down we will have
a) SiteMinder with IIS (public facing site)
b) Apache Reverse Proxy ( For routing)
c) Tomcat Application (For routing and a logic for site access based on time)
d) Backend applications
The reason for bringing the new architecture is that all back end applications have code for site access. The site can be down for some time, which is controlled by a property file.
I find this architecture wrong. I do not understand why Apache Reverse Proxy is requried. I would still go with simple architecture with flow as
a) SiteMinder with IIS doing the routing -> Backend Applications(accessing a common service to check whether site can be accessed or not)
Am I missing something?
The Apache reverse proxy would make it easier to load balance between multiple IIS instances. As far as I know to do something similar on IIS you would need to use the ARR (application request routing) module which won't be optimised to work with Tomcat etc.
However, the SiteMinder with IIS does seem an added overhead in your architecture. The Apache reverse proxy also supports SiteMinder agents. Why don't you push for setting up the SiteMinder agent on the Apache proxy and remove IIS completely from the picture. I can think of the following benefits:
Remove one extra layer from the architecture
Remove an extra network hop
Clean up the stack. Apache + Tomcat is very standard in enterprises while IIS + Apache + Tomcat definitely isn't.
Hope this helps
I don't see either the rationale behind the second architecture. The first scenario is a much more common deployment of Siteminder.
Be aware that this kind of architecture potentially opens vulnerabilities (logon bypass notably). See my answer on this question. Those remarks are true for both architectures.

Authentication with CAS for rest service call

In our current setup we have about a dozen web applications that deploy to a single Tomcat server. One of these applications is CAS which is used for all authorization.
This works pretty well and in our jRuby web application we use the rubycas-client gem, point to CAS and we're done.
Now we have a requirements where, in a Java component, we need to be able to call out to another web application via a rest service that resides on the same server. My first thought was to use CAS proxy tickets but the web application we have to hit currently doesn't have this enabled and, due to the nature of the environment, this cannot be changed.
So as far as I can tell we're left trying to impersonate the user by using an iframe in our web application that points to the other one (we're all on the same domain and server) and scrape its sessionid for impersonation and pass it down to the Java layer. But I really, really don't want to do this.
Am I missing anything? Is there any better ways of doing this? Is there a way to get the sessionid without an iframe maybe?
Thanks!
If you want to call a web service from a web application using CAS identity, you certainly should use the CAS proxy feature.
If you can't cassify your web service, there is another option for you : you could use the Apache module for CAS : https://wiki.jasig.org/display/CASC/mod_auth_cas.

How I can deploy my GWT application on www

I created my first Java EE application (GWT + Hibernate). I want deploy my application on a Tomcat web server.
Could you give me a step by step tutorial?
You can start with Google App Engine + GWT tutorial if you are trying out deploying into Google Cloud - https://developers.google.com/web-toolkit/doc/latest/tutorial/appengine
This question is massive so I will try to bring it down to some steps that need some research to implement.
1st. You created an application using GWT and Hibernate. That means that you need some kind of a web server that understands java and can re-write the logic from java to javascript (for the clientside), and also connect to the database on the serverside and retrieve the data for the client.
This web server is tomcat so what you need is:
A computer that will work as a server. This could be your own machine or some server you can buy as a hosting solution. Buying something like this requires research and effort on your part and cannot be explained here.
A version of Tomcat or Resin or any other web server that understands java
A domain name. These can be bought from sites like this one, but there are some free ones around the web. They require static ips that is you cannot use them from a home line that changes ips. Even without a domain name you can host your site on the server but you need to access it by writing the machine's ip instead. - optional - A temporary solution would be to use some kind of dynamic dns service on your router.
After having set up tomcat (you might want to give port 80 to tomcat) and the server you can host your application by uploading the war file. You can make a war file from gwt by following the instructions here
To upload the war file you can use the tomcat manager interface, or you can connect to the server and place it manually in the folder used for the web applications.
I know that each step propably needs as much if not more explanation by I hope I cleared the area a little bit here.