Let webservice use SSL - ssl

With WildFly 8.2.1, I am trying to make existing webservice (JAX-WS) use SSL, but I haven't seen any use of SSL in quickstarts and the information I was able to google is limited. So far I've added this to web.xml:
<security-constraint>
<display-name>Foo security</display-name>
<web-resource-collection>
<web-resource-name>FooService</web-resource-name>
<url-pattern>/foo/FooService</url-pattern>
<http-method>POST</http-method>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
and this is in my standalone.xml:
<subsystem xmlns="urn:jboss:domain:webservices:1.2">
<wsdl-host>${jboss.bind.address:127.0.0.1}</wsdl-host>
<endpoint-config name="Standard-Endpoint-Config"/>
<endpoint-config name="Recording-Endpoint-Config">
<pre-handler-chain name="recording-handlers" protocol-bindings="##SOAP11_HTTP ##SOAP11_HTTP_MTOM ##SOAP12_HTTP ##SOAP12_HTTP_MTOM">
<handler name="RecordingHandler" class="org.jboss.ws.common.invocation.RecordingServerHandler"/>
</pre-handler-chain>
</endpoint-config>
<client-config name="Standard-Client-Config"/>
</subsystem>
but apparently that's not enough; when I look into standalone/data/wsdl/foo.ear/foo.war/FooService/Bar.wsdl I see:
<service name="FooService">
<port binding="foowsb:FooBinding" name="FooBinding">
<soap:address location="http://localhost:8080/foo/FooService"/>
</port>
</service>
Note that in the EAR/WAR, the soap:address.location is filled just with a placeholder (I suppose that the value is ignored).
I've found some info about setting up security realm, and creating the self-signed certificate using keytool (which I did), but I completely miss how this should be linked together.
I've also tried to setup wsdl-uri-scheme=https, but this is supported only in later versions of CXF.

Seems that the soap:address.location value is not ignored when it's being replaced, since changing that from REPLACE_WITH_ACTUAL_URL to https://REPLACE_WITH_ACTUAL_URL did the trick - now the service got exposed on https://localhost:8443.
There is a couple of more steps I had to do in standalone.xml: in undertow, add https-listener:
<https-listener name="secure" socket-binding="https" security-realm="SslRealm"/>
define the SslRealm:
<security-realm name="SslRealm">
<server-identities>
<ssl>
<keystore path="foo.keystore" relative-to="jboss.server.config.dir" keystore-password="foo1234" alias="foo" key-password="foo1234"/>
</ssl>
</server-identities>
<authentication>
<truststore path="foo.truststore" relative-to="jboss.server.config.dir" keystore-password="foo1234"/>
</authentication>
</security-realm>
Note that I reuse the same keystore for server and clients here. And since my clients are ATM in the same WF node during development, I had to setup the client-side part there, too:
<system-properties>
<property name="javax.net.ssl.trustStore" value="${jboss.server.config.dir}/foo.keystore"/>
<property name="javax.net.ssl.trustStorePassword" value="foo1234"/>
<property name="org.jboss.security.ignoreHttpsHost" value="true"/>
</system-properties>
The last property should be replaced in WF 9+ with cxf.tls-client.disableCNCheck.

Related

How to verify wildfly web server is using added keystore file for https connection?

I have created a self-signed certificate(public_certificate.crt), private key file(private_key.pem). and these are stored in keystore file keystore.jks.
I have configured the same keystore.jks file in the standalone.xml file of widlfly 10 in two section as:
Section 1:
<security-realm name="UndertowRealm">
<server-identities>
<ssl>
<keystore path="keystore.jks" relative-to="jboss.server.config.dir" keystore-password="changeit" />
</ssl>
</server-identities>
</security-realm>
Section 2:
<server name="default-server">
<http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>
<https-listener name="https" socket-binding="https" security-realm="UndertowRealm" enable http2="true"/>
<host name="default-host" alias="localhost">
<location name="/" handler="welcome-content"/>
<filter-ref name="server-header"/>
<filter-ref name="x-powered-by-header"/>
</host>
</server>
I have restarted the server, now when i am accessing the wildfly url(https://localhost:8443) it is coming as "Not Secure" in the browser url section of chrome.
I am having two question related to it:
With or Without configuring the standalone.xml file with our keystore, chrome is mentioning "Not Secure" in browser URL section. it might be because i am using self-signed certificate. but my question is, how will i know that my self-signed certificate is being used by Wildfly.
Is there any way to avoid "Not Secure" warning and it should be coming as "Lock" symbol in the browser for self-signed certificate.

Wildfly many domains with many ssl certificate

I've got test server and I would like to run many applications on that instance, but there's a problem with SSL certificates. If I'm using single certificate, everything is ok, but if when I add another, there is a problem.
This is my ssl realm configuration :
<security-realm name="ssl-realm">
<server-identities>
<ssl>
<keystore path="cert_one.jks" relative-to="jboss.server.config.dir" keystore-password="1234" key-password="1234"/>
<keystore path="cert_two.jks" relative-to="jboss.server.config.dir" keystore-password="1234" key-password="1234"/>
</ssl>
</server-identities>
</security-realm>
And this is my undertow server configuration:
<server name="default-server">
<http-listener name="default" socket-binding="http"/>
<https-listener name="defaultHttps" socket-binding="https" security-realm="ssl-realm" max-post-size="31457280"/>
<host name="one_app" alias="firstapp.com">
<filter-ref name="server-header"/>
<filter-ref name="x-powered-by-header"/>
</host>
<host name="two_app" alias="secondapp.com">
<filter-ref name="server-header"/>
<filter-ref name="x-powered-by-header"/>
</host>
</server>
As you can see I have two different certificate keystores, one for firstapp.com and another for secondapp.com.
But only certificate for secondapp.com is working. If I delete one of those keystores everything is OK. How to configure two or more certificates for different domains in Wildfly configuration?

When using Basic Authentication for war deployed in WildFly, getUserPrincipal returns null

I have been attempting to get a simple Basic Authentication example working with WildFly 8.1.0, immutant, and friend. I'm willing to post any code desired, but I'm not sure what would be needed at this point. For now, I'll assume my standalone.xml, web.xml, and jboss-web.xml all contain the correct data -- that may not be the case, but for now I'll just dive in to the problem.
I have an application with a simple /test resource. I've deployed it on WildFly and use Basic Authentication to attempt to access it. Also, I've checked my application-roles.properties and application-users.properties files and they seem fine.
When I attempt to log in, I see the following trace from WildFly:
14:30:36,681 TRACE [org.jboss.security] (default task-1) PBOX000210:
defaultLogin, login context:
javax.security.auth.login.LoginContext#4c89fc2c, subject:
Subject(1313538088).principals=org.jboss.security.SimplePrincipal#99148614(tester-na)org.jboss.security.SimpleGroup#83654093(Roles(members:elm-nss-admin))org.jboss.security.SimpleGroup#83654093(CallerPrincipal(members:tester-na))
The user is tester-na and you can see that it is a member of elm-nss-admin.
When I use a bad password, WildFly catches it and my application never does any check. However, when I sent the correct password the above trace is logged and it calls my authentication handler.
The problem is that my authentication handler fails because a call to getUserPrincipal() returns NULL. The resource is protected, here are my security constraints:
<security-constraint>
<web-resource-collection>
<web-resource-name>Protected Resources</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>*</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
When I use LDAP, this isn't a problem. I think it's because LDAP supplied a certificate and WildFly passes up the cookie.
But with Basic Auth, I'm not getting a cookie, I won't barf the debug output unless requested, it's quite verbose, but the relevant bits are: :cookies {}, :context , :session nil
I'm guessing that getUserPrincipal() fails because I'm still in the act of authenticating?
So, any ideas on how I can get the user data/permissions from WildFly so friend can be passed the proper data to authenticate/authorize with?
#
Update: I was able to create a simple application with the same XML files I'm using for the production app and it isn't failing. For interest, and those who use stackoverflow for answers as much as I do, here are the relevant parts:
From standalone.xml in security-realms:
<security-realm name="ApplicationRealm">
<authentication>
<local default-user="$local" allowed-users="*"/>
<properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
</authentication>
<authorization>
<properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
</authorization>
</security-realm>
and in <subsystem xmlns="urn:jboss:domain:security:1.2"> I have:
<security-domain name="other" cache-type="default">
<authentication>
<login-module code="Remoting" flag="optional">
<module-option name="password-stacking" value="useFirstPass"/>
</login-module>
<login-module code="RealmDirect" flag="required">
<module-option name="password-stacking" value="useFirstPass"/>
</login-module>
</authentication>
</security-domain>
<security-domain name="jboss-web-policy" cache-type="default">
<authorization>
<policy-module code="Delegating" flag="required"/>
</authorization>
</security-domain>
<security-domain name="jboss-ejb-policy" cache-type="default">
<authorization>
<policy-module code="Delegating" flag="required"/>
</authorization>
</security-domain>
In my web.xml file (in the war-resources/WEB-INF folder):
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>ApplicationRealm</realm-name>
</login-config>
The jboss.xml file, in the same directory is:
<jboss-web>
<context-root></context-root>
<security-domain>other</security-domain>
</jboss-web>
Since these settings are working with my simple application, I'll start looking for something project specific as to why WildFly isn't giving me the user in my production code.
Any helpful suggestions would be greatly appreciated. Even just a suggestion as to where to start looking.
#
Problem solved. Turns out the user was being logged out before I was attempting to authorize access to a specific resource. :P
Steven solved the problem himself:
Problem solved. Turns out the user was being logged out before I was
attempting to authorize access to a specific resource. :P

Glassfish 3.1.2 configuration Client Certificate for Mutual Authentication

I need help in configuring GF3.1.2 i have done following changes, please do let me know if i am missing anything important as after changes it is NOT working.
my id is nilesh2811#gmail.com
I could not found any particular thread or answers in forum if any link is there will be helpful.
if you have any document for this please forward.
please do the needful
web.xml
<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>
<security-constraint>
<web-resource-collection>
<web-resource-name>Entire Application</web-resource-name>
<url-pattern>/faces/*</url-pattern>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<description/>
<role-name>authorized</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<security-role>
<description/>
<role-name>authorized</role-name>
</security-role>
sun-web.xml
<security-role-mapping>
<role-name>authorized</role-name>
<principal-name>admin</principal-name>
<group-name>authorized</group-name>
</security-role-mapping>
domain.xml
<security-service>
<auth-realm classname="com.sun.enterprise.security.auth.realm.file.FileRealm" name="admin-realm">
<property name="file" value="${com.sun.aas.instanceRoot}/config/admin-keyfile"></property>
<property name="jaas-context" value="fileRealm"></property>
</auth-realm>
<auth-realm classname="com.sun.enterprise.security.auth.realm.file.FileRealm" name="file">
<property name="file" value="${com.sun.aas.instanceRoot}/config/keyfile"></property>
<property name="jaas-context" value="fileRealm"></property>
</auth-realm>
<auth-realm classname="com.sun.enterprise.security.auth.realm.certificate.CertificateRealm" name="certificate">
<property name="assign-groups" value="authorized"></property>
</auth-realm>
The login-config section is incomplete in your web.xml
<login-config>
<auth-method>CLIENT-CERT</auth-method>
<realm-name>certificate</realm-name>
</login-config>
The realm-name content must match the name attribute of auth-realm element in domain.xml, which in your case is "certificate"
[updated]
In addition, the CA certificate must be imported in the server's truststore
${com.sun.aas.instanceRoot}/config/cacerts.jks
Actually I tries on glassfish 3.1.2 and it worked under following conditions:
1.I have to use the same key(trust) store of jks type and in the same location. In order to talk with other certificate formats you have to convert them to format jks format can handle.
2.in a glassfish-web.xml you should have like this mapping
<security-role-mapping>
<role-name>manager</role-name>
<group-name>authorized</group-name>
</security-role-mapping>
3.in a domain.xml file you should have the followings:
<auth-realm classname="com.sun.enterprise.security.auth.realm.certificate.CertificateRealm" name="certificate">
<property name="assign-groups" value="authorized"></property>
</auth-realm>
Note: in web.xml you have to have realm name matching domain.xml file
When anyone will try this first time it will take time for them to understand, withing simple words, both client and server trust-stores should trust each other certificates, first it is better to use Self-signed certificates exchange certificates to server and client, one can use following article for help which has simplified steps. follow article then you can use your own methods certificates which ever u want.
http://www.slideshare.net/krizsan/scdjws-5-study-notes-3085287
SCDJWS 5
or nowadays know as
Oracle Certified Professional,
Java EE 5 Web Services Developer
Study Notes
by
Ivan A Krizsan
Version: February 23, 2012
Set
Client Authentication: true
in http-listener-2.

Cannot get SSL to work on Azure instance

I've been tearing my hear out trying to figure out why SSL works in one of my Azure projects but not in another.
When I navigate to my site, say https://foo.com, I can't even connect to the site. Browsers can't connect at all and curl says "couldn't connect to host". However, if I go to my cloudapp.net URL (e.g. https://foo.cloudapp.net), it can connect but browsers will complain and say my cert is for *.foo.com. Note: I am able to connect to http://foo.com without any trouble.
Here's my code with certain values obfuscated.
ServiceDefinition.csdef:
<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="MyApp" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
<WebRole name="www" vmsize="Small">
<Sites>
<Site name="Web">
<VirtualApplication name="r" physicalDirectory="../Foo/Bar" />
<Bindings>
<Binding name="Endpoint1" endpointName="Endpoint1" />
<Binding name="Endpoint2" endpointName="Endpoint2" />
</Bindings>
</Site>
</Sites>
<Endpoints>
<InputEndpoint name="Endpoint1" protocol="http" port="80" />
<InputEndpoint name="Endpoint2" protocol="https" port="443" certificate="STAR.foo.com" />
</Endpoints>
<Imports>
<Import moduleName="Diagnostics" />
</Imports>
<Certificates>
<Certificate name="STAR.foo.com" storeLocation="LocalMachine" storeName="My" />
</Certificates>
</WebRole>
</ServiceDefinition>
my cert is uploaded, the thumbprint matches (in this example it's also "1234567890")
ServiceConfiguration.csfg:
<?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration serviceName="myApp" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" osFamily="1" osVersion="*">
<Role name="www">
<Instances count="2" />
<ConfigurationSettings>
<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
</ConfigurationSettings>
<Certificates>
<Certificate name="STAR.foo.com" thumbprint="1234567890" thumbprintAlgorithm="sha1" />
</Certificates>
</Role>
</ServiceConfiguration>
Azure Console:
I have verified that:
My cert is uploaded
It's SHA1
It's thumbprint matches what I've specified in ServiceConfiguration.cscfg (in this example it's "1234567890")
The certs for the Certificate Authorities are also present (for me it's "PositiveSSL CA" and "AddTrust External CA root")
For the Azure instance, it confirms there are 2 endpoints (port 80 and port 443)
Why would I not be able to connect at all via https://foo.com, but my https://foo.cloudapp.net will load (although triggering a browser warning)? This seem to indicate my configuration is correct but something else is off... ideas?
I think you may be looking in the wrong place for your problem!
How have you mapped foo.com to your site's address?
Note that Azure instances are given dynamic IP addresses - what address your site may be on NOW may not be what its on tomorrow. The recommendation for Azure is to add a "www" CNAME DNS entry in your domain records that points at "foo.cloudapp.net".
This way, when someone browses to www.foo.com, the DNS server will (invisibly) say "hey, actually, that site is as foo.cloudapp.net. The browser will then ask for the IP address of foo.cloudapp.net. This domain is managed by Microsoft who will return the current IP address for your site.
If you want foo.com to still get you to www.foo.com, you'll have to setup DNS redirection so that whenever someone types foo.com into their browser, they're redirected to www.foo.com. This will then cuase the browser to resolve foo.cloudapp.net and then the HTTP request will be sent to your site. Some domain hosters charge for this (typically a nominal fee), some offer it as a free service.
HTH.