Over two years ago I’ve blogged on how to share the forms authentication between ASP.NET and ClickOnce applications. We use this technique often for it’s just convenient to have just one, centralized authentication mechanism (ASP.NET Membership Provider in this case) in large modular systems.
In just few words – that sharing is possible by passing a Forms authentication cookie to the ClickOnce application as an Uri parameter and append the cookie to the CookieContainer of a webservice proxy class. This way all requests from the ClickOnce application back to the server (which pass through the FormsAuthenticationModule) are correctly recognized as authenticated and in the same time an exception is thrown in case of a missing or invalid authentication cookie. On the server side – web service methods are guarded with the PrincipalPermission attribute. Please, refer to the article for more details.
As we finally add Silverlight to our daily toolbox, I strongly needed a corresponding mechanism for WCF Services and Silverlight proxies. I need to share the Forms authentication between my ASP.NET hosting application and the Silverlight application users run after they login to the ASP.NET application.
What seemed to be a piece of cake, has turned out to be tricky, mostly because of the way in which exceptions are passed between the server and the Silverlight at the client side.
Guarding WCF calls with PrincipalPermission – an easy step
The first step is easy. Since Silverlight is hosted in web browser, there’s no need to copy cookies as cookies are appended automatically to WCF service calls (assuming that both hosting application and hosted Silverlight come from the same domain but this is usually the case). Assuming then that users need to login first using Forms authentication and then they get access to the Silverlight application, whenever the Silverlight calls back the WCF on the server, Forms authentication cookies are there.
So I just happily put PrincipalPermission over my WCF methods but unfortunately no matter whether I logged first or not, I got an exception all the time. It seems that WCF needs an few additional spells to be casted for this to work (and these spells was not needed for ASP.NET WebServices):
- an additional AspNetCompatibilityRequirements attribute over the WCF class
- setting Thread.CurrentPrincipal in the WCF constructor
[ServiceContract( Namespace = "http://my.namespace.com/service1" )]
[AspNetCompatibilityRequirements( RequirementsMode = AspNetCompatibilityRequirementsMode.Required )]
public class Service1
{
public Service1()
{
/* this line is crucial for PrincipalPermission to work */
Thread.CurrentPrincipal = HttpContext.Current.User;
}
... WCF methods follow ...
- forcing the runtime to use ASP.NET compatibility mode for WCF (web.config)
...
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
...
</system.serviceModel>
Having all these prepared, I can safely guard my WCF business methods with PrincipalPermission attribute and exceptions are thrown back to the client in case of unauthenticated users.
...
public class Service1
{
[OperationContract]
[PrincipalPermission(SecurityAction.Demand, Authenticated=true)]
public int DoWork( int i )
{
return i;
}
Detecting the Forms Cookie timeout – a slightly more difficult step
Unfortunately, I cannot stop at this point. This is because Forms Authentication cookies do timeout. For ASP.NET application this is not a problem – the FormsAuthenticationModule just redirects the call to the LoginPage so users just relogin. For ClickOnce/WebService – I can catch SOAPExceptions, take a look at the Message and check whether it says something about PrincipalPermission. If this is so, I can relogin my users with an additional unguarded Web Service method which just reappends valid Forms Authentication cookies to the proxy’s cookie container.
In my WCF/Silverlight scenario, the timeout of the Forms cookie is a disaster. All consecutive WCF requests still contain the Forms cookie but the cookie is not valid anymore and the PrincipalPermission attribute causes these calls to fail. An exception from the inside of server’s runtime environment is returned to the client as just “The remote server returned an error: Not found”. My chance to detects the actual cause of the exception is zero. “Not found” does not mean “Your cookie has just timed out!”.
What I need is to use two independent mechanisms:
- I have to catch principal permission issues explicitely on the server so that …
- … I can explicitely pass it to Silverlight and catch on the client side
Let’s start from the latter, since it’s more obvious – there’s an explicit way of passing exceptions from the server to Silverlight using FaultContract.
FaultContract is an attribute on my service class with tells WCF how to pass exceptions to the client.
The former can be achieved by using an imperative way of permission demanding – rather than using PrincipalPermissionAttribute, we will use the PrincipalPermission and call it’s Demand method so that we can catch the exception of the server side, wrap it into the FaultContract and send it to the client.
Let’s start from the FaultContract at the server side:
/* note that this does not inherit from the Exception class ... */
[DataContract]
public class MyException
{
[DataMember]
public int Code { get; set; }
[DataMember]
public string ActualException { get; set; }
}
[ServiceContract( Namespace = "" )]
[AspNetCompatibilityRequirements(
RequirementsMode = AspNetCompatibilityRequirementsMode.Required )]
public class Service1
{
public Service1()
{
Thread.CurrentPrincipal = HttpContext.Current.User;
}
[OperationContract]
/* ... because this is the FaultContract which inherits from Exception */
[FaultContract( typeof( MyException ) )]
public int DoWork( int i )
{
Inside our business method we have to check if the call is authenticated and if not – we wrap it in a FaultException instance.
There’s still one caveat however – MSDN claims that in Silverlight, FaultContracts have to be handled using a WCF Behavior Extension due to some limitations of the web browser’s stack. Fortunately, someone has pointed that much simpler way – I just need to cast a single-line spell inside the business method so that exceptions are passed with 200 OK instead of 500 Internal Server error and the FaultContract can be consumed at the Silverlight’s client side:
[OperationContract]
[FaultContract( typeof( MyException ) )]
public int DoWork( int i )
{
/* a powerfull spell so that I do not need a WCF
Behavior Extension as MSDN says
*/
System.ServiceModel.Web.WebOperationContext
.Current.OutgoingResponse.StatusCode =
System.Net.HttpStatusCode.OK;
/* Check for principal permissions explicitely rather than
using the attribute */
/* I do not need any special username/role but I need
calls to be authenticated */
PrincipalPermission p = new PrincipalPermission( null, null, true );
try
{
p.Demand();
}
catch ( Exception ex )
{
/* wrap the exception so that Silverlight can consume it */
MyException fault =
new MyException()
{
/* Code = 1 will mean "unauthenticated!" */
Code = 1, ActualException = ex.Message
};
throw new FaultException<MyException>( fault );
}
return i;
}
This is all at the server’s side, let’s go back to the Silverlight client and call the service:
private void Button1_Click( object sender, RoutedEventArgs e )
{
ServiceReference1.Service1Client c = new Service1Client();
c.DoWorkCompleted +=
new EventHandler<DoWorkCompletedEventArgs>( c_DoWorkCompleted );
/* cannot try-catch here as this is an asynchronous call */
c.DoWorkAsync( 5 );
}
void c_DoWorkCompleted( object sender, DoWorkCompletedEventArgs e )
{
/*
Note that e.Error is set whenever an exception is raised from somewhere.
However, this time instead of "Not found." we have the FaultContract passed
to the client.
*/
HandleFaultException( e.Error );
MessageBox.Show( e.Result.ToString() );
}
/* A generic method to handle WCF exceptions */
void HandleFaultException( Exception ex )
{
/* Is it my custom Fault sent to the Client? */
if ( ex is FaultException<MyException> )
{
FaultException<MyException> exception = (FaultException<MyException>)ex;
/* Is the Code == 1? Remember the convention - 1 means "unauthenticated" */
if ( exception.Detail.Code == 1 )
{
/* Do whatever you like but now you know
what's the reason of the exception */
/* You can for example redirect the Silverlight
application to ASP.NET Login page
so that the user relogins and will likely run
the Sliverlight application again */
HtmlPage.Window.Navigate( new Uri( "loginPage.aspx", UriKind.Relative ) );
}
}
}
Happy coding.
