Index syndication
comment syndication

Attempt to Deploy Netflix Edda on Wildfly 8.x

I’ve been trying to find a production platform for Edda, the Netflix OSS app for tracking AWS resources.

The application is written in Scala, which gets compiled as Java bytecode. The build toolset used by Netflix is gradle, and they deploy the application for testing into Jetty. Jetty can be used in a production environment, but the setup that comes with the build set with Edda is not really designed with a production server in mind. That said, a lot of people just end up running Edda by manually running up Jetty as a background process on a Linux box. Since I’ve been using Java application servers for quite a number of years (Websphere AS, Tomcat, Glassfish); I understand the need to run compiled Java web apps in production infrastructure. Therefore, I have been trying to find a reliable, OpenSource Java Web Application Server (WAS) to host Edda.

I’ve been thinking of trying out JBoss in the past, and the 8th major release of Jboss is now known as Wildfly, it seemed like a likely target for deploying Edda to.

The gradle build of Edda produces a WAR file, ready for deployment to a WAS. However, the war file from the gradle build won’t deploy by default on Wildfly, as shown with this error:

01:12:50,021 ERROR [org.jboss.as.server] (XNIO-1 task-10) JBAS015870: Deploy of deployment "edda-2.1.war" was rolled back with the following failure message: 
{"JBAS014671: Failed services" => {"jboss.undertow.deployment.default-server.default-host.\"/edda-2.1\"" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host.\"/edda-2.1\": Failed to start service
    Caused by: com.sun.jersey.api.container.ContainerException: The ResourceConfig instance does not contain any root resource classes."}}

Edda uses Jersey (a standard and portable JAX-RS API) for RESTful Web services, but the WAR file won’t deploy properly with the servlets configured to use Jersey. This is due to the fact that Jersey is no longer a (default) option for JAX-RS web services on Wildfly. It comes integrated with RestEasy as the JAX-RS implementation instead.

Using RestEasy makes it necessary to change your Web.xml file because Jersey and RestEasy have different deployment configurations. This will likely to apply to any Wildfly 8.2 release, even though I’m using 8.2.0

The solution for Edda; is to modify the web.xml that gets built into the WAR file. I’ve committed the modification for web.xml to a branch on my fork of Edda. This solves the deployment issue when you try to deploy Edda as a WAR file into Wildfly.

Yet after all this; I can’t actually get Edda to work properly on Wildfly.

In the end I went for the good old Tomcat Java Web App Server, and Edda runs with an out of the box build.

ADFS2 is not always SAML 2.0 standards compliant

Now the madness with ADFS2 SAML assertions via WS-Trust 1.3 – and how they are not valid for use with Amazon Web Services (AWS).

lexx:saml$ aws sts assume-role-with-saml --role-arn $role --principal-arn $principal --saml-assertion $assertion
A client error (InvalidIdentityToken) occurred when calling the AssumeRoleWithSAML operation: Responses must contain SubjectConfirmatonData with a Recipient and NotOnOrAfter

This failed due to a missing Recipient attribute on the SubjectConfirmationData element. Of course; I can’t modify the assertion to add the missing Recipient; as the SAML token is signed:

lexx:saml$ aws sts assume-role-with-saml --role-arn $role --principal-arn $principal --saml-assertion $assertion
A client error (InvalidIdentityToken) occurred when calling the AssumeRoleWithSAML operation: Response signature invalid

Second fail is because I’ve modified the assertion to add the missing attribute; but now the signature is invalid.

When you get an assertion from the ADFS Identity Provider via the IdP Web Landing Page, for AWS, the assertion includes a “recipient”:

<subjectconfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
  <subjectconfirmationdata NotOnOrAfter="2015-02-08T22:48:18.520Z" Recipient="https://signin.aws.amazon.com/saml"></subjectconfirmationdata>
</subjectconfirmation>

When you ask for an assertion from the WS-Trust 1.3 endpoint; it is missing:

<subjectconfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
  <subjectconfirmationdata NotOnOrAfter="2015-02-09T05:03:10.517Z"></subjectconfirmationdata>
</subjectconfirmation>

Seems to be a common problem with ADFS2 whereby ADFS1 did it correctly. It’s not just me

In the original SAML 2.0 Core spec – Line 725 – Recipient is an optional attribute in the SubjectConfirmationData element. However in subsequent errata for the specification, Errata 02 in May 2007, made it mandatory. Errata 05 still includes this requirement.

At lease one bearer element MUST contain a element that itself MUST contain a Recipient attribute containing the service provider’s assertion consumer service URL

Of course; Amazon adhere to the Standard:

The value of the Recipient attribute inside the SubjectConfirmationData element must match the AWS endpoint (https://signin.aws.amazon.com/saml)

It seems that ADFS2 doesn’t provide valid SAML 2.0 assertions issued via the WS-Trust 1.3 endpoint. Since this has been a standard since for almost 8 years, how does ADFS2 even claim to be standards based.

SAML assertion from ADFS2 via SOAP endpoint

According to Wikipedia, Microsoft Active Directory Federation Services (ADFS) is:

… a software component developed by Microsoft that can be installed on Windows Server operating systems to provide users with single sign-on access to systems and applications located across organizational boundaries. It uses a claims-based access control authorization model to maintain application security and implement federated identity.

ADFS can provide Single sign as an identity provider to users, but what if a developer needs the same sign on outside of “browser land”? One option is to scrape webpage responses, but a better option is receiving a SAML Assertion using SOAP endpoints exposed via Microsoft ADFS, as long as they are enabled. You can use SOAP 1.2 with WS-A Addressing and mixed message security with the username/password in the SOAP headers secured over HTTPS, and get a valid SAML assertion.

There is Mex Endpoint (Anonymous by default) provided by ADFS2 or greater (if not disabled) at
https://youradfsserver.com.au/adfs/services/trust/mex
If you want to play with SOAP based claim requests, use a tool like SoapUI and consume the Mex endpoint as the WSDL. You can then construct Soap messages, and see if you get a valid response – which would contain an assertion.

The SOAP Endpoint for requesting a SAML token using WS-Trust 1.3 and mixed security would be
https://youradfsserver.com.au/adfs/services/trust/13/usernamemixed

The client credentials are included in the header of a SOAP message. Confidentiality is preserved at the transport layer (SSL/TLS); hence a usernamemixed endpoint.

Here is an example SOAP request for usernamemixed:

You can also use curl to post the soap request as shown:

Given all that; this actually won’t work for AWS; given ADFS2 actually breaks the SAML2.0 standards updated in 2012. Next post will detail this.

Is SNI viable?

Traditionally if one was to secure a web server using TLS (or previously, SSL) – then one would configure your web server to use TCP port 443 to listen for TLS requests from clients (browsers). When a browser connects to the web server using the HTTPS protocol, the server would encrypt the communications and all would be well with the world.

A problem occurs when you use name based Virtual Hosting on your web server. If you need to determine the client request before providing content from a virtual host, e.g. blah.com vs. blahblah.com, then this couldn’t be done if you encrypted the communications using TLS. Enter stage left: Server Name Indication.

According to Wikipedia:

Server Name Indication is a feature that extends the SSL and TLS protocols. It permits the client to request the domain name before the certificate is committed to the server. This is essential for using TLS in virtual hosting mode.

I’ve a need to use Server Name Indication (SNI) for some freelance IT work I perform, but colleagues shy away from SNI since Internet Explorer on Windows XP is unsupported.

Is this an issue? Are so many people still on Windows XP that it will diminish the security aspects of implementing SSL to secure input of personal data ?

One of the best places to determine OS usage trends in Australia would be from Google, but they don’t provide such data. Therefore I turn to another source of data: StatCounter. They have been providing stats to websites and business for well over 10 years, so their data should be viable.

Source: StatCounter Global Stats – OS Market Share


The chart above shows Operating system usage for 2014 in Australia. Windows XP sits at 4 percent usage at the end of 2014. For an operating system that’s now unsupported and 4 Major versions old; it just shouldn’t be considered anymore.

Source: StatCounter Global Stats – Combine Chrome (all versions) & Firefox (5+) Market Share

The second chart shows browser usage statistics in 2014. Internet Explorer 6, which doesn’t support SNI, isn’t even on the chart anymore.

Knowing the actual statistics – the usage of Internet Explorer 6 (or a lesser version) and Windows XP seems to be so minimal that usage of SNI is a viable option; especially where it gives a rise to cost saving on implementation of x509 certificates on web front ends. What do you think?

Next entries »