Index syndication
comment syndication

Windows 10 UEFI USB Boot in VMWare Fusion 7

You’ve downloaded your purchased Windows 10 ISO from Microsoft, and you’ve managed to create a bootable UEFI USB stick.
Now you’ve decided to run Windows 10 in VMWare Fusion Pro on your Mac. Yet the USB stick can NOT be booted from.
There is a solution. VMWare fusion has some (unsupported) EFI options you can enable to effect a USB boot.
First you’ll want to create a Windows 10 VM in VMWare Fusion.
Create a new VM, and select the more options icon:
Setup-1
Select Create a custom virtual machine and select Continue:
Setup-2
Select Windows 10 as the operating system, and select Continue – x64 is selected here as I’m 64 bit all the way:
Setup-3
Leave the virtual disk options and select Continue:
Setup-4
On the Summary Screen, you can use the Customize Settings button to change your VM defaults. I updated my RAM to 8GB, my CPU Cores to 2, and changed the VM Disk size to 100GB (60GB may be a bit small for most power users).
Setup-Summary
Before you start the VM; you’ll need to modify the vmx file directly.

  1. In the Virtual Machine Library, right click on the Windows 10 VM and select Show in Finder.
  2. Right click on the vmwarevm container and select Show Package Contents
  3. Edit the *.vmx file using your favourite text editor
  4. Append the following options to the configuration to enabled EFI booting:

firmware = "efi"
efi.legacyBoot.enabled = "true"

Show-VMX
Edit-vmx
The Legacy boot option allows VMWare to see the USB device in some cases; and was required for me.
Boot your new VM:
Start-VMWare
You’ll find that the new EFI boot loaders are picked up, but not yet the USB. Since you couldn’t attach a USB before starting, you can do it now. Open the VM preferences and attach the USB containing the EFI Boot files:
Connect-EFI-USB
VMWare will now boot into the Windows 10 setup.
Restart-VMWare-Windows10
Thanks to a post by A Virtual Den for pointing me in the right direction for the VMX LegacyBoot option!

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.

Next entries »