February 2010 - Posts

Dominick just blogged what I think is one of the best ways to provide claim based security for RESTful services at the moment. The idea of using simple web tokens for RESTful services I’ve been in my head for a while, but I was not able to find enough the time to implement it. Fortunately, Dominick already did it for us, so it’s really great to have a sample with that.

One piece that is still missing in this architecture is the possibility to run an in-house STS for issuing simple web tokens rather than using the ACL service available as part of Windows Azure AppFabric. It would be great if we could have some built-in support in WIF to issue simple web tokens, in other words, a built-in security handler for simple web tokens, and a RESTful endpoint for requesting those. 

The OAuth Wrap specification (the place where the simple web tokens are defined) also supports the typical ActAs scenario, where a client application can request a token on behalf of the logged user. This would be ideal for example, in a web application that want to consume a RESTful service on behalf of the logged user.    

Posted by cibrax | 1 comment(s)
Filed under: , ,

The Federation Authentication Module (FAM) shipped as part of WIF protects by the default the session cookies from being tampered with in passive scenarios using DPAPI. As I mentioned in the past, this technique simplifies a lot the initial deployment for the whole solution as nothing extra needs to configured, the automatically generated DPAPI key is used to protect the cookies, so this might be reason to have that as default protection mechanism in WSE, WCF and now WIF.

However, this technique has some serious drawbacks from my point of view that makes it useless for real enterprise scenarios.

If web application that relies on FAM for authenticating the users is hosted in IIS. The account running the IIS process needs to have a profile created in order to use DPAPI. A workaround for this is to log into the machine with that account to create the initial profile or run some script to do it automatically.

DPAPI is not suitable for web farm scenarios, as the machine key is used to protect the cookies. If the cookie is protected with one key, the following requests must be sent to the same machine. A workaround for this could be to use sticky sessions, so all the user requests from the same machine are handled by the same machine on the farm.

Fortunately, WIF already provides some built-in classes to replace this default mechanism by a protection mechanism based on RSA keys with X509 certificates.

The “SecuritySessionHandler” is the handler in WIF that is responsible for tracking the authentication sessions into a cookie. That handler receives by default some built-in classes that applies transformations to the cookie content, such as the DeflatCookieTransform and the ProtectedDataCookieTransform (for protecting the content with DPAPI). There are also two other CookieTransform derived classes that are not used at all, and becomes very handy to enable enterprise scenarios, the RSAEncryptionCookieTransform and RSASignatureCookieTransform classes. Both classes receives either a RSA key or X509 certificate that is used to encrypt or sign the cookie content.

Therefore, you can put the following code in the global.asax file to replace the default cookie transformations by the ones that use a X509 certificate.

protected void Application_Start(object sender, EventArgs e)
        {
            FederatedAuthentication.ServiceConfigurationCreated += new EventHandler<Microsoft.IdentityModel.Web.Configuration.ServiceConfigurationCreatedEventArgs>(FederatedAuthentication_ServiceConfigurationCreated);
           
        }

        void FederatedAuthentication_ServiceConfigurationCreated(object sender, Microsoft.IdentityModel.Web.Configuration.ServiceConfigurationCreatedEventArgs e)
        {
            var cookieProtectionCertificate = CertificateUtil.GetCertificate(StoreName.My,
                StoreLocation.LocalMachine, "CN=myTestCert");
            
            e.ServiceConfiguration.SecurityTokenHandlers.AddOrReplace(
                new SessionSecurityTokenHandler(new System.Collections.ObjectModel.ReadOnlyCollection<CookieTransform> (
                    new List<CookieTransform>
                    {
                        new DeflateCookieTransform(),
                        new RsaEncryptionCookieTransform(cookieProtectionCertificate),
                        new RsaSignatureCookieTransform(cookieProtectionCertificate)
                    })
                ));
        }

Posted by cibrax | 2 comment(s)
Filed under: , ,

Windows AppFabric (Previously known as Dublin) introduces a new built-in mechanism for monitoring the execution of the WCF services, all the events generated during the execution or the interaction with other services. While the message trace capabilities in WCF already provided some detail about the execution and the exchanged messages, it was a feature more suitable for troubleshooting and error diagnosis.   The performance counters did not help in this area either, as they provided live service usage statistics, which sometimes resulted very useful to determine possible bottlenecks.

When this monitoring mechanism is enabled for IIS Hosted services, the AppFabric extension will capture different events during the execution of the services. The level of detail or number of events that you want to capture is something that can be adjusted through configuration.

In order to configure monitoring for an existing WCF service, you need to add the following section to the web.config file,

<microsoft.applicationServer>
    <monitoring>
     
      <default enabled="true" connectionStringName="DefaultApplicationServerExtensions" monitoringLevel="Troubleshooting" />
    </monitoring>
</microsoft.applicationServer>

The connectionStringName attribute should contain a reference to an existing connection string in the ConnectionString section, and that’s the database used by AppFabric to store the monitoring events.

The monitoringLevel attribute specifies the number of events you want to capture in a service execution. The possible values for this setting are,

  • Off (monitoringLevel="Off”): No data is collected. It would be equivalent to have monitoring disabled.
  • Errors only (monitoringLevel="ErrorsOnly”):  Only errors and warnings events are collected. This is very useful when you don’t want to incur into performance issues for collecting application events but you still want to know about any error may happen during the execution.
  • Health Monitoring (monitoringLevel=HealthMonitoring): This is the default level and collects enough application events to show different metrics in the AppFabric dashboard.
  • End To End Monitoring (monitoringLevel="EndToEndMonitoring”). It collects all the events from the Health Monitoring level, plus additional events to reconstruct the message flow. For example, Service A called Service B. You will get also events representing info about the Service B call if monitoring is enabled on Service A.
  • Troubleshooting (monitoringLevel="Troubleshooting"). This is the most verbose of all, so it is appropriate for troubleshooting an unhealthy application.

All this monitoring infrastructure is layered on top of “Event Tracing for Windows (ETW)”, which provides a very efficient and optimized mechanism for capturing application events without affecting the application performance at all. In addition, this infrastructure is complemented with a windows service for collecting the events (A ETW listener basically), and providers for dumping all the information to different storages. This last part is totally extensible, and you can configure your own implementation by implementing the interface Microsoft.ApplicationServer.Monitoring.EventCollector.IBulkCopy in the Monitoring.ApplicationServer.Monitoring assembly. This interface looks quite simple to implement, and AppFabric ships with a default implementation for SQL Server.

public interface IBulkCopy
{
        int BatchSize { get; set; }
        DbConnection Connection { get; set; }
        string DestinationTableName { get; set; }

        void WriteToServer(DataTable dataTable);
}

The windows service for collecting the ETW events can be found under the folder, C:\Windows\System32\ApplicationServerExtensions\Microsoft.ApplicationServer.ServiceHost.exe, and it must be started in order to capture and dump the events in the configured IBulkCopy provider.

In addition, if you want to correlate all the service calls within a single execution (For example, Service A calling Service B, and B calling C) under a unique global identifier, so you can group all the events under that identifier, there is a new <endToEndTracing> element under the <system.ServiceModel/diagnostics> section that you can use.

<system.ServiceModel>
  <diagnostics etwProviderId="7d98f890-ff8d-4311-be4f-e679103ba7cf">
    <endToEndTracing propagateActivity="true" messageFlowTracing="true" />
  </diagnostics>
</system.ServiceModel>

For example, the following image shows two events that are correlated under the same E2EActivityId, which represents a service “HelloWorld” calling an operation in another “EchoService” service.

EndToEndTracing

Posted by cibrax | 3 comment(s)
Filed under: , ,
More Posts