Index syndication
comment syndication

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?

Jive for Office 2013 64bit

A client I’m consulting for is using Jive as their EDRMS of choice. It’s not bad; but after using Office 365 recently, Jive is not as integrated as you’d like with Office 2013.

Working in the cloud (Jive is a cloud EDRMS) requires that another client you may connect from have the appropriate client plugin. In the case of Office 2013, you need to install the Jive plugin from their community website. It’s not easy to find, but it can be found.

The first issue I hit after installing this is that the 64bit version of Office 2013 disabled the COM Add-In. This occurred using the Jive extension version 30.1.655.15760.

After digging around on the support community pages; there is a registry fix to make the plugin compatible with x64 office clients. The one provided was for Office 2011; so I’ve included here a modified registry file for Office 2013 64bit edition.

Steps to get the extension working are:

  • Uninstall the Jive for Office extension.
  • Import this registry file for windows:

  • Reinstall the JiveOfficeInstaller.msi

After that; success!

Jive extension now working in Office 2013 x64

Jive extension now working in Office 2013 x64

 

Next entries »