(Solution) "Secure channel cannot be opened because security negotiation" (Geneva)

Today, I was doing some tests with the Geneva (Beta) Framework, again.

It took me some time to find the source of the following errors/exceptions my test applications where throwing:

• Secure channel cannot be opened because security negotiation with the remote endpoint has failed. This may be due to absent or incorrectly specified EndpointIdentity in the EndpointAddress used to create the channel. Please verify the EndpointIdentity specified or implied by the EndpointAddress correctly identifies the remote endpoint.
  
• The message could not be processed. This is most likely because the action 'http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue' is incorrect or because the message contains an invalid or expired security context token or because there is a mismatch between bindings. The security context token would be invalid if the service aborted the channel due to inactivity. To prevent the service from aborting idle sessions prematurely increase the Receive timeout on the service endpoint's binding.

The problem was that my testclient was using a different bindingtype then my test Security Token Service.

For more information about what type of binding to favour, see: http://webservices20.blogspot.com/2009/04/which-binding-to-use-wshttpbinding-or.html

Perhaps this is usefull for you.

Forget Role Based Security! (Geneva)

With the arrival of the Beta 1 of the "Geneva" Claims Based Access Platform you should forget everything you know about role-based security.

Claims based security is everything! It really  is!

Especially in any SAAS,  Heterogeneous or WCF-Services environment using Security Token Services is the technology to use... But honestly, it should be the security route for any solution!

I recommend reading this excellent document by David Chappel which gives a perfect conceptual (no code) explanation of what "Claims Based Access" and "Geneva" are about.

I also recommend reading this excellent document by Keith Brown which gives a perfect introduction (with code) to the whole "Geneva" suit!

For more informatie see msdn: http://msdn.microsoft.com/en-us/security/aa570351.aspx

Note: the "Geneva" framework cannot be installed on Windows XP nor on Windows 2003. A temporarily solution can be found here: http://travisspencer.com/blog/2009/02/installing-geneva-framework-on.html

Happy Claiming!

WCF Windows Service (Debugging)

Seeing the popularity of SOA rising, Microsoft's WCF services are rightfully being used more and more. Ofcourse, those services need to be hosted somewhere. One of the options for this is in a Windows Service (or technically speaking in a Process Service).

But, with the development of Windows Services comes the, generally accepted, burdon of deploying (compiling, installing, starting, attaching debugger, stopping, uninstalling) these services with every change we make, atleast if we do this by the book.

Not settling for that situation I counted my (too many) options and choose the following stratagy:

1) As goes without saying, allways make sure your service has hardly any "guts". Have all the logic in a seperate class that is seperately and indepentdently unittested.

2) Add a "program.cs" to your WindowsService-project, change its type to "Console Application" finally have Visual Studio start that project up when you start debugging your solution. (see source here: Run-windows-service-as-a-console-program.

Happy Servicing


Notes:

• Don't worry, by changing the type to "Console Application" you only tell Visual Studio to start (technically speaking "exec"-buildtask) the main-function of the program.cs you can still deploy your services without any changes to the sources/binaries.
  
  
• Try to group your Services in one Windows Services (technically speaking adding multiple appdomains to the process). If applicable this does save a significant amount of memory.
  
  
• Microsoft's upcoming OSLO concept might make this approach less needed;
  
  
• Add the following configuration block to your "app.config" to get usefull Console output:

<system.diagnostics>
  <trace autoflush="false" indentsize="4">
   <listeners>
    <add name="configConsoleListener"
type="System.Diagnostics.ConsoleTraceListener">
   </listeners>
  </trace>
</system.diagnostics>

Microsoft WCF Tools (Test, Configure, UI)

With SOA and Web v2.0 everything is about services.

As you know for Microsoft the current strategic tool of choice for services is WCF. However, testing / configuring with WCF, among things can be tricky. Knowing what tool to use in what situation is essential. As it turns out still not everybody knows about the currently available tools from Microsoft, so just as a reminer below a list:

• ServiceModel Metadata Utility Tool (Svcutil.exe): Generates service model code from metadata documents and metadata documents from service model code;
• Find Private Key Tool (FindPrivateKey.exe): Retrieves the private key from a specified store.
• ServiceModel Registration Tool (ServiceModelReg.exe): Manages the registration and un-registration of ServiceModel on a single machine. COM+
• Service Model Configuration Tool (ComSvcConfig.exe): Configures COM+ interfaces to be exposed as Web services.
• Configuration Editor Tool (SvcConfigEditor.exe): Creates and modifies configuration settings for WCF services.
• Service Trace Viewer Tool (SvcTraceViewer.exe): Helps you view, group, and filter trace messages so that you can diagnose, repair, and verify issues with WCF services.
• WS-AtomicTransaction Configuration Utility (wsatConfig.exe): Configures basic WS-AtomicTransaction support settings using a command line tool.
• WS-AtomicTransaction Configuration MMC Snap-in: Configures basic WS-AtomicTransaction support settings using a MMC snap-in.
• WorkFlow Service Registration Tool (WFServicesReg.exe): Registers a Windows Workflow service.
• WCF Service Auto Host: Hosts WCF services contained in libraries (*.dll) files
• WCF Test Client: GUI tool that allows you to input parameters of arbitrary types, submit that input to the service, and view the response the service sends back.

You can find all information about there tools here.

There are also a few Debugger Visualizers for WCF available aswell:
http://codeplex.com/WCFVisualizer

Be aware though, Oslo is coming up about to change this big time!

Happy Serviceing!