Custom SSL TrustManager for Java App server - jboss

I'm trying to setup SSL connections for a web service that is B2B and need to do client authentication on the server. Since the server hosts URLs that are also accessible from regular users through browser, not all connections to the host need to do client-auth. Only specific URLs require client-auth to validate the callers X509 certificate. We are using JBoss 5.x, which is based on Tomcat 5.x so I have a connector configuration like so:
<Connector protocol="HTTP/1.1" SSLEnabled="true"
port="8443" address="${jboss.bind.address}" sslProtocol = "TLS"
scheme="https" secure="true" enableLookups="true" clientAuth="false"
keystoreFile="${jboss.server.home.dir}/conf/.myKeyStore"
keystorePass="password1" />
As you can see I have a keystore configured so we can provide our Signed Cert and I have clientAuth=false as the specific URLs needing client-auth will be configured in web.xml like so:
<security-constraint>
<web-resource-collection>
<web-resource-name>clientAuthResources</web-resource-name>
<url-pattern>/clientauth/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>authOnly</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>CLIENT-CERT</auth-method>
<realm-name>myRealm</realm-name>
</login-config>
<security-role>
<role-name>authOnly</role-name>
</security-role>
Through a custom JAAS Login module I can actually get this to work IF in the connector config above I also specific a truststore that has the client certs. That is where my issue is. Given the setup of our application and how we scale, each jboss application server setup supports a specific segentation of our users and I do not want truststores configured all over the place on the file system. We need to load the trusted certificates dynamically in code from our database. The custom JAAS login moduble does this at web level, and it also assignes roles, however without the connector truststore the login module never gets called, connection is terminated at SSL level before HTTP getes involved.
After much research on the web I've determined I need a custom X509TrustManager configured in the SSLContext/SSLSocketFactory to get around this. This custom trust manager would also validate client certs off the ones stored in our database. I have created this custom trust manager, however I cannot seem to hook it up. Does anyone know a way to configure this in jboss or tomcat 5.x? I noticed in Tomcat 7 the following config is available on a connector, trustManagerClassName, however that is not an option for me. I assume its possible, any help is greatly appreciated.

You can write your own org.apache.tomcat.util.net.jsse.JSSEImplementation and pass its full class name in the SSLImplementation attribute of your connector.
See examples here:
http://code.google.com/p/jsslutils/wiki/ApacheTomcatUsage
http://code.google.com/p/jsslutils/source/browse/trunk/extra/apachetomcat5/src/main/java/org/jsslutils/extra/apachetomcat5/JSSLutilsImplementation.java
http://code.google.com/p/jsslutils/source/browse/trunk/extra/apachetomcat5/src/main/java/org/jsslutils/extra/apachetomcat5/JSSLutilsJSSESocketFactory.java

Related

How to enable single sign-on across different applications deployed in the same WildFly server

I have multiple applications deployed to a single WildFly server, version 26.1.2. Those applications have the same application security domain specified in their jboss-web.xml files.
Chapter Web Single Sign-On of WildFly Elytron Security explains how to enable single sign-on across different applications deployed into different servers, where these applications belong to same security domain.
I guess there must be an easier way to do this when all applications are running on the same server. I will appreciate any help you can provide on this matter.
This is the jboss-web file of application xyz2ap112-web:
<jboss-web>
<context-root>/xyz2ap112-web</context-root>
<resource-ref>
<res-ref-name>jdbc/xyz2db112</res-ref-name> <!-- Logical name only. -->
<jndi-name>java:/jdbc/xyz2db112</jndi-name> <!-- Real JNDI name. -->
</resource-ref>
<security-domain>xyz2ap112-web-security-domain</security-domain>
</jboss-web>
Actually the applications also share the same database, so the only difference between their jboss-web.xml files is the context root.
This is the login configuration for all the applications in their web.xml file:
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/faces/login.xhtml</form-login-page>
<form-error-page>/faces/error.xhtml</form-error-page>
</form-login-config>
<realm-name>xyz2ap112-web-security-domain</realm-name>
</login-config>
This is the definition of the application security domain in the standalone-full.xml file:
<application-security-domain name="xyz2ap112-web-security-domain" security-domain="xyz2db112-jdbc-security-domain"/>
This is the definition of the security domain in the standalone-full.xml file:
<security-domain name="xyz2db112-jdbc-security-domain" default-realm="xyz2db112-jdbc-realm" permission-mapper="default-permission-mapper">
<realm name="xyz2db112-jdbc-realm" role-decoder="groups-to-roles"/>
</security-domain>

How to redirect HTTP to HTTPS in Wildfly10?

My requirements are,
1. Application URL should have http, domain name/ipaddress, no port number
2. Application need to redirected to https
3. And again port number should not be visible
4. All need to be doe in wildfly
Application URL should have http, domain name/ipaddress, no port number
Try configuring apache before JBoss instance
Application need to redirected to https
add redirect-port="443" to http connector as follows :
<connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http" redirect-port="443"/>
Configure https connectory in configuration file(standalone.xml/domain.xml)

Implement CAS Single Sign Out for Cross Domain Applications

I am a beginner in using CAS. My CAS server is up and running at port 8443(Secured HTTP layer). I have also made two applications - JAVA Client(My own JAVA Client) and PHP Client(Officially provided by CAS) for testing my CAS server. I am able to use single Sign On for both of the clients. I have also enabled Single Sign Out in the CAS properties file. My current version of CAS is 4.0.0 and I am using Apache Tomcat version 8.0.23
I have added the following dependency for Sign Out in web.xml for JAVA Client
<filter>
<filter-name>CAS Single Sign Out Filter</filter-name>
<filter-class> org.jasig.cas.client.session.SingleSignOutFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>CAS Single Sign Out Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<listener>
<listener-class> org.jasig.cas.client.session.SingleSignOutHttpSessionListener</listener-class>
</listener>
But while performing Single Sign Out, When I log out of PHP Application I am unable to log out of already opened JAVA Applications. This means that on logging out from PHP application does not destroy my existing JAVA Application Sessions.
So after a lot of research I came across this and I was successfully able to implement Sign Out feature. But I do not want to use a common session database.
In the official documentation of CAS it is mentioned that:
CAS sends an HTTP POST message directly to the service ( back channel communication): this is the traditional way of performing notification to the service.
When CAS is configured for SLO, it attempts to send logout messages to every application that requested authentication to CAS during the SSO session.
But I am unable to understand how to fetch the SLO message as I do not receive any POST request( while tracking using firebug) during logout of an application. So Can anyone please help me to perform Single Sign Out.
Thanks in advance.
As found on CAS documentation:
When a CAS session ends, it notifies each of the services that the SSO session is no longer valid, and that relying parties need to invalidate their own session.
This can happen in two ways:
CAS sends an HTTP POST message directly to the service (back channel communication): this is the traditional way of performing notification to the service.
CAS redirects (HTTP 302) to the service with a message and a RelayState parameter (front channel communication): This feature is inspired by SAML SLO, and is needed if the client application is composed of several servers and use session affinity. The expected behaviour of the CAS client is to invalidate the application web session and redirect back to the CAS server with the RelayState parameter.
Usage Warning!
Front-channel SLO at this point is still experimental.
(emphasis added by me)
If you do not see corresponding activity on the browser, you are probably using option #1 where POST messages are send on the backend.
SLO is way more complicated than SSO...

GWT, SSL and Glassfish. Is there SSL now?

Sorry if this will be too common or simple question but I don't know what should I put into Google to finaly find the answer.
I have GWT application which is now currently running on Glassfish. I can run the application on port 8080 (http) or 8181 (https). The thing is - am I using SSL now?
Default self signed certificate is enough for me for now (I know about keytool and import certificates), I just have to clarify this simple question.
I red here GWT and SSL not working? I need to set up security-constraint in web.xml
<security-constraint>
<web-resource-collection>
<web-resource-name>sslprotect</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
Is this enough then? In the comments Sam writes something about "implement the whole usage of SSL correctly."
So question: Is this enough? Is my application SSL protected now?
To be honest, I studied security algorithms on the University but I failed in implementation misserably.
It should be enough. If you can see the https in front of your URL, everything is fine. You can check if you are SSL-protected by browsing to the http URL, this should return an error or redirect you to the https URL.

How do I deploy to nexus (hosted by secureci)?

Like recommended in a previous SO-Answer I'm running a VmWare image of secureci as a preconfigured development infrastructure containing maven, nexus, hudson, svn.
Now I want to configure maven on my Windows XP machine to deploy its artifacts to nexus. But when I configure my pom.xml like this (taken from Deploying Artifacts to Nexus):
<distributionManagement>
<!-- use the following if you're not using a snapshot version. -->
<repository>
<id>nexus</id>
<name>RepositoryProxy</name>
<url>scp://192.168.0.197/nexus/content/repositories/releases</url>
</repository>
<!-- use the following if you ARE using a snapshot version. -->
<snapshotRepository>
<id>nexus</id>
<name>RepositoryProxy</name>
<url>scp://192.168.0.197/nexus/content/repositories/snapshots</url>
</snapshotRepository>
</distributionManagement>
... mvn deploy prints the error message:
Error deploying artifact: Exit code: 1 -
mkdir: cannot create directory `/nexus': Permission denied
In settings.xml I configured username and password like this:
<servers>
<server>
<id>nexus</id>
<username>tangens</username>
<password>********</password>
</server>
</servers>
Question: What configuration do I have to use for deploying to nexus?
I already tried https instead of scp, but with this maven ran into problems with missing certificates.
I tried http instead of scp, but secureci has a firewall installed to block access to port 80 (http), causing a timeout.
EDIT:
I found that nexus stores its artifacts at /root/sonatype-work/nexus/storage/snapshots/. But I don't like the idea to enter the credentials of the root account in my settings.xml.
EDIT:
Q: Did you enabled deployment for a hosted repository under Nexus?
Yes, it's enabled by default.
Q: Is Nexus listening on port 80?
There is an apache running on port 80.
Server: Apache/2.2.8 (Ubuntu) DAV/2 SVN/1.4.6 mod_ssl/2.2.8 OpenSSL/0.9.8g mod_wsgi/1.3 Python/2.5.2
Q: If a firewall is not allowing HTTP, why don't you just add an exception for HTTP connections from the "host" IP?
Because I assumed SecureCI is well configured and there should be a way to do it without tweaking the installation. But perhaps I'm too naive here.
The error is clear: the user tangens doesn't have the permission to create /nexus on the remote machine. Actually, your scp url is not correct and isn't pointing to the right location as you mentioned it. You'd have to give the user tangens the right permission or to configure sshd to allow root to connect but this is not a good idea.
Having that said, I don't think that scp is the way to go with Nexus. If you deploy using scp, Nexus won't be notified of the deployment and your artifacts won't be visible. According to Deploying Artifacts to Nexus and to the chapter 9.4.2. Update the POM: Deployment Configuration of the Nexus book, deployment must be done with HTTP PUT. In other words, your distributionManagement section should look like something like this:
<distributionManagement>
...
<repository>
<id>releases</id>
<name>Internal Releases</name>
<url>http://localhost:8081/nexus/content/repositories/releases</url>
</repository>
...
</distributionManagement>
I noticed you said that SecureCI uses a firewall that is configured to drop connections on port 80. However, as I'm not using SecureCI myself, I have a few (maybe stupid) questions:
Did you enabled deployment for a hosted repository under Nexus?
Is Nexus listening on port 80?
If a firewall is not allowing HTTP, why don't you just add an exception for HTTP connections from the "host" IP?
EDIT: According to the OP answers, I think that using HTTPS might be indeed the "natural" way to go with SecureCI. But, before you can upload via HTTPS, you'll need to add the SecureCI's CA certificate (the certificate of the issuer of their certificate) into your JDK. You can follow these instructions to do this. But before going further, the real question is:
Does SecureCI provide the CA certificate (the certificate of the issuer of their certificate)?
If they don't, I don't know how to make deployment possible without tweaking the firewall rules.
Sorry. Just came across the question.
There are two options, as other posters have mentioned: supply the certificate to Maven or turn on HTTP access and open port 80 (which is closed by default for security).
For enabling HTTP access, see /trac/secureci/wiki/HowTo/EnableHttp in SecureCI (under the HowTo docs on the wiki, How do I enable HTTP access?).
For the certificate, the public and private key are in /etc/apache2/ssl/.
If you want to replace the default cert, the docs for installing your own (which could be self-signed or signed by a recognized CA) are in the SecureCI wiki at /trac/secureci/wiki/HowTo/InstallSslCert (under the HowTo docs on the wiki, How do I install an SSL certificate?). The location of the existing cert is noted there as well.