Index syndication
comment syndication

Archive for integration

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.

PowerShell to Configure BizTalk Server 2013 Host and Host Instances

Everyone loves automated processes.

With BizTalk 2013 if you want to provide a repeatable install; you need automation. PowerShell is where it’s at.
Lucky for me, other very skilled people already have written PowerShell scripts providing the capability to create hosts and host instances. Sandro Pereira has written and published a PowerShell script to create your BizTalk host instances based upon the best practice of host separation. However, it’s only written for BizTalk 2010.

I’ve gone and modified it for BizTalk 2013. It provides the exact same capability, with BizTalk 2013 capabilities.
This includes new Receive Port Handlers:

  • SB-Messaging
  • SFTP
  • WCF-BasicHttpRelay
  • WCF-NetTcpRelay

And New Send Port Handlers:

  • SB-Messaging
  • SFTP
  • WCF-BasicHttpRelay
  • WCF-NetTcpRelay
  • WCF-WebHttp (the new adapter supporting REST)

The diff to the BTS2010 version from Sandro is:

You can grab my updated BizTalk 2013 script over at my BizTalk 2013 GitHub repository.

Microsoft Development

I’ve started down the path of Darkness 🙂

In December 2011, I went on BizTalk training with @BizTalkBill and I’m now four weeks into the next stage of my career which is being an Microsoft “Integration Specialist”. You won’t find any open source in this realm, no ruby, nothing involving indie developers cracking out code until late at night.

What this change means is getting to know Visual Studio, BizTalk, SQL Server and all things Microsoft. It means using TFS, even though you really want to use Git. It means C# coding when you are familiar with interpreted languages like Perl, PHP and Ruby (I won’t be doing an ASP work).

That means you can expect going forward less posts about Unix, Clearcase (finally!) and Open Source platforms, and more about Microsoft offerings; specifically integration products.

Welcome to 2012.