(Click here to download my Security-Interop-Sample) (Click here for downloading the presentation)
While I am here at PDC studying the most exciting new stuff from Microsoft around Software+Services and much more interesting platform-enhancements (Dublin, Velocity, Geneva etc.) I promised about more than a week ago at the DevCamp 2008 conference in Vienna that I will publish some details about a demo on security I've shown in my session about applying concepts from the Identity Meta System Vision in the real world for heterogeneous environments.
The session itself was all about taking the separation of concerns in terms of authentication and authorization that is proposed by federated identity patterns. Furthermore it was about learning, how this SoC can help you solving real world problems when it comes down to implementing security in your solutions.
Click here for downloading the presentation. I'd strongly recommend you do this before moving on in this post!
In the last demo I've shown a Security Token Service (STS) written with Microsoft Codename "Zermatt" that authenticates requests coming from a .NET-based client application through Windows Authentication and transforms the (proprietary;)) Windows-token into a standards-based SAML-token. Why that? Well, non-Windows based platforms won't be able to deal with a proprietary Windows-token for authorizing requests - especially if they're not running on Windows. But they will be able to work with SAML as it is just a signed XML with information about an authenticated user proofed by an identity provider (the security token service). The following picture shows the scenario I've implemented:
In this post I give you a step-by-step guide how-to setup the samples which you find for download under the following link:
Click here to download my Security-Interop-Sample
In the following sections I summarized the pre-requisites and steps you need to complete for making the sample above work!
Steps to make the Microsoft / .NET Side running:
Make the Java-Side working
Now, after the .NET-based solution is running, we can move forward by making the Java-version of our claims-based web service running. For that purpose follow the subsequent steps:
Final steps and then running the application
After you have configured Glassfish, configured the Java Web Service and deployed it, successfully, you can try the interoperability solution between Java and .NET. For this purpose you need to update the .NET test-client’s configuration to point to your running Java web service and then run the application. The URL to the Java-service is configured in the client’s App.config (NET.TestClient in my sample solution) as shown in the following screen-shot:
Just one last step before running it – you need to update the STS so that it encrypts the SAML-token with the certificate of your Glassfish Java Web service. As these certificates are re-generated for each machine you need to update my code in the sample to make it work. Update the certificate-name in the project “SimpleActiveSTS-VS2008” of my solution in the file “MySecurityTokenService.cs” and change the common name of the certificate to yours (you should only need to replace the machine-name part of the common name which is “vaiom” in my sample and should be “yourmachinename” in your environment):
After you have updated this one you can try to run the solution and instead of calling the .NET-based service you can call the Java-service by entering “java” instead of “net” when the client asks you which web service it should call. The following screen-shot shows the resulting application in action.
In the console-windows you can see the .NET-based applications running: the claims-aware web service which is not called in this scenario, the security token service which issues a SAML-token based on the Windows identity the client authenticates with and the client itself that calls the Java service this time. In the background you can see the Netbeans IDE with the Glassfish output Window where clearly the Java application outputs the contents of the SAML token it gets passed from the STS. That SAML token just contains claims extracted from the Windows-token the client authenticated with against the STS. And that way we managed to make security-interoperability happen by transforming a proprietary Windows-token to a standardized SAML-token through an STS and give Java access to the contents of the Windows-token. Of course the Java-application could run on a Linux-box as well and still you would be able to use Windows and AD as the primary identity management system for managing users, groups etc. and include Java-services (or other services) running on any OS with your security-infrastructure as they don’t need to know about any details of the security infrastructure. The only thing they need to know is the Security Token Service which proofs the fact that the user has been authenticated successfully by passing a signed SAML-token through the client to the Java-service. In my opinion that shows one of the things that unveil the real power of a federated identity infrastructure based on the WS-* standards...
If you have any feedback or questions, feel free getting in touch with me through my blog;) ... of course I'd be happy about any feedback:)