I'm trying to configure my Spring application to use an SSL certificate I purchased from a CA. I followed the directions for the Tomcat 6.0 configuration and have imported the key into my Tomcat keystore and uncommented the SSL connector in the server.xml. When I start Tomcat, I see the connector start on port 8443 in the Tomcat logs, but when I go to https://example.com:8443 or http: //example.com:8443 or https: //example.com (without the spaces - I don't have the reputation to post links), it times out. What other configuration do I need to do to enable SSL for my Spring application. Do I have to change the application configuration?
I'd also like to only have some URLs over SSL (login, edit profile, etc.). How can I allow this in the Spring configuration? If I have to have all URLs accessible over SSL, that would be ok, but not desirable. I haven't found any tutorials that are Spring specific.
What you'll need to do is to edit your server.xml file to enable ssl. Here's Tomcat's guide, please check it out:
http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html
In order to programmatically know if a request has arrived through port 80 or 443, you need to inspect the value returned by request.isSecure().
To secure URLs altogether, I'd recommend using a Filter.
I don't remember how all of this is handled by Spring, but I don't think you'll have any problems to obtain the request object.
Hope that helps.
After you've configured Tomcat as per the document cited by #mschonaker, he simplest thing is to define the action in the j_security_check and edit profile forms, etc, specify the https: protocol, e.g. in a Facelet, https://#{request.serverName}:8443#{request.contextPath}/j_security_check. Then when the user hits the login button, the form POSTs via HTTPS, so they are secure.
This leaves you in HTTPS for the rest of the session: to get back to HTTP but still stay in the same session, just provide a link to a fully-specified HTTP url, e.g. in a Facelet, http://#{request.serverName}:8443#{request.contextPath}/some link.
If you have other pages you want secured when read, define appropriate security-constraint, user-data-constraint, and transport-guarantee CONFIDENTIAL elements for them in web.xml.
about the second point
I'd also like to only have some URLs over SSL (login, edit profile, etc.). ???
you could determine it by modify configration in web.xml
<security-constraint>
<web-resource-collection>
<web-resource-name>securedapp</web-resource-name>
<!-- <url-pattern>/*</url-pattern> --> <!--all pages-->
<url-pattern>/yourapp/login</url-pattern>
<url-pattern>/yourapp/edit</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
hope that help you
Related
In the Spring definition of a remote resource that is protected via OAuth2 to which the client application wants access, I set use-current-uri to true, in other words, the current URI should be used as a redirect (if available). It looks like:
<oauth:resource id="myResourceId" type="authorization_code"
client-id="${clientId}" client-secret="${clientSecret}"
access-token-uri="${accessTokenUri}"
user-authorization-uri="${userAuthorizationUri}"
use-current-uri="true"
scope="myScope"
pre-established-redirect-uri="${preEstablishedRedirectUri}"/>
Now the problem is, the Spring Security OAuth2 client will pick up the current internal Tomcat URL instead of the public web application's URL. The scenario is Tomcat server sitting behind Apache server, which results in two sets of URLs:
The public web application's URL is http://example.com/users/login
The internal Tomcat URL is http://localhost:8080/myapplication/users/login
Because the redirection URL is for the authorization server (e.g., Twitter, ORCID) to use to send back the authorization code, the public web application's URL should be used, not the internal one.
By the way, I'm using the following version of spring-security-oauth2:
spring-security-oauth2-1.0.5.RELEASE
spring-core-3.1.2.RELEASE
spring-security-core-3.1.3.RELEASE
Wonder if there is a way to tell Spring to use the public URL. Thanks.
Inside your tomcat conf/server.xml's connector element , try setting your public URLs that front tomcat like this:
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"
proxyName="example.com"
proxyPort="443" (or whatever port you are using, same goes for scheme )
scheme="https" />
This way tomcat's internal getServerName and getServerPort methods will start giving the correct values which hopefully should create the correct URL.
You might also want to configure your webserver to route requests falling at
http://example.com/users/login to http://localhost:8080/myapplication/users/login if not already done.
When I put below url which exists on Server, I get the 404 error
localhost/PDFDemo/resources/jquery/css/ui-lightness/images/ui-bg_highlight-soft_100_eeeeee_1x100.png
Error 404--Not Found
From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:
10.4.5 404 Not Found
The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.
If the server does not wish to make this information available to the client, the status code `403 (Forbidden)` can be used instead. The `410 (Gone)` status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address.
I had same problem for javascript files and resolved the issue by putting below in web.xml
<mime-mapping>
<extension>js</extension>
<mime-type>text/javascript</mime-type>
</mime-mapping>
Are there equivalent codes for jsp and images which I can put in contextConfigLocation(eg : servlet.xml).
The problem is that you are mapping the Spring Dispatcher Servlet to the root context, so Spring wants to handle every request (which isn't in itself a problem if you have it configured correctly). Adding something like this:
<mvc:resources mapping="/resources/**" location="/public-resources/" cache-period="31556926"/>
Modified for your environment should work. See the documentation for allowing static resources to bypass Spring and go to the default servlet here.
You should also add this to your config so that Spring knows to use the Default Servlet.
<mvc:default-servlet-handler/>
Also, answers to this question may help you.
Good day. I'm developing a Java web app with Servlets\JSP using Tomcat 7.0. During request from client I put and object into the session and use forward. After the forward processing the same request the object can be retreived if the secure parameter is false otherwise it is not stored in session.
<session-config>
<session-timeout>15</session-timeout>
<cookie-config>
<http-only>true</http-only>
<secure>true</secure>
</cookie-config>
<tracking-mode>COOKIE</tracking-mode>
</session-config>
I've figured out that "...cookies can be created with the 'secure' flag, which ensures that the browser will never transmit the specified cookie over non-SSL...". I've configured Tomcat to use SSL, but that haven't helped. Changing the tracking mode to SSL haven't helped as well. How do session-config and HttpSession object correlate in this case? What could be the problem?
I'm looking to disable jsessionid from being used in the https headers.
Is there a way to turn this off or disable this being set as a cookie in tomcat 7?
I either want the jsessionid to arrive embedded into a GET method url name value pairs or to be part of a POST request name value pairs.
I know all the advantages and disadvantages of using cookie based sessioning and url rewriting but I have specific needs for specific impl of restful web services.
I need tomcat 7 to accept jsessionid without using the http header: jsessionid.
Thanks.
UPDATE:
so I looked around some more and found this which is implemented using the web.xml conf.
However the following doesn't seem to work with Tomcat 7.
<session-config>
<tracking-mode>URL</tracking-mode>
</session-config>
is it a case of TC7 not fully implementing the servlet 3.0 spec?
The web.xml setting works for me with Tomcat 7.0.20.
Log and check the effective (and maybe the default) session tracking modes:
logger.info("default STM: {}" , servletContext.getDefaultSessionTrackingModes());
logger.info("effective STM: {}" , servletContext.getEffectiveSessionTrackingModes());
Maybe your app override somewhere in the code the session tracking modes. An example:
final Set<SessionTrackingMode> trackingModes =
Collections.singleton(SessionTrackingMode.COOKIE);
servletContext.setSessionTrackingModes(trackingModes);
Check ServletContext.setSessionTrackingModes() calls in your code.
It's also possible to set default session tracking modes in the Tomcat's context settings but I found that web.xml settings override them.
i'm developping a web app (jsf 2.0 + facelets + richfaces 3.3.3 + oracle 10g + tomcat 6.0.26)
in my app, there's is 1 path that is not secured, and the others are secured (web.xml):
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/faces/login.jsp</form-login-page>
<form-error-page>/faces/error.jsp</form-error-page>
</form-login-config>
</login-config>
<security-constraint>
<web-resource-collection>
<web-resource-name>Admin_Resource</web-resource-name>
<description/>
<url-pattern>/faces/admin/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>A</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<security-role>
<description>Role admin</description>
<role-name>A</role-name>
</security-role>
So, this path is not secured: /faces/client/*.
when i move from https tp http, i use this function:
FacesContext.getCurrentInstance().getExternalContext().redirect("http://url/faces/client/page.xhtml");
When i deploy my app, and use this url: http(s)://url/MyContext/faces/..., all worked fine.
But when i moved my app to the ROOT context, so i use this url : http(s)://url/faces/, my https session is lost when i move from https to http, then back to https. My login page shows up, so i need to re-type my login and password.
Why is my session lost ? Is there something wrong ?
Add: when i deploy my app, here's what i do (external server):
put my war file into webapp folder
start my server (that will decompress my war into folders,...), then stop it
i delete my war file
i replace the content of ROOT folder with the content of the decompressed war file
and restart my server again
but all works fine when i put my war into webapp folder, then start the server (that's all).
So, i think it's a context problem.
Do you have any ideas ?
This an old question but it's worth answering because I just ran into it and the answer ended up being really simple. First, it makes complete sense that the session should be regenerated on the same session cookie name when going back and forth between HTTP and HTTPS. By default in Tomcat the session cookie name is JSESSIONID.
In Tomcat you can very simply change the name of the session cookie. I had two webapps, one HTTP and another HTTPS, for admin tools. Anytime the HTTP webapp opened I lost my session in the HTTPS webapp. All I had to do was add the sessionCookieName to the context of my HTTPS webapp:
<context sessionCookieName="ANOTHERCOOKIENAME" ...
This won't help if you're switching between HTTP and HTTPS in the same webapp, but you shouldn't do that anyway.