I have a Silverlight 4 client that invokes several WCF services. We want the communication to be encrypted using SSL (I have this part solved already) and that every call be authenticated against AD LDS (ADAM), do you have any simple example showing how to make this work? There's plenty of documentation on the oh-so-many WCF options but I haven't been able to find a simple working example of this particular (but I think very common) scenario (SSL encryption + ADAM authentication + Silverlight). Any help or pointers greatly appreciated.
You can use CustomUserNameValidator in WCF:
http://msdn.microsoft.com/en-us/library/aa702565.aspx
http://nayyeri.net/custom-username-and-password-authentication-in-wcf-3-5
and in Custom Validator's Validate Method you can query ADAM to authenticate user.
Regards.
Try this link on the Codeplex website, it seems like the setup and configuration for the scenario you've described. It provides a thorough checklist of all of the required settings:
Intranet – Web to Remote WCF Using Transport Security (Trusted Subsystem, HTTP)
If this isn't you exact scenario, take a look at the following section that may fill the gaps:
Application Scenarios (WCF Security)
The answer may depend on how you will handle permissioning, since you use ASP.net's membership provider for these functions.
If you want claims based authorization ADFS 1.0 (not 2.0) supports ADAM. If you want a STS that has more options try codplex's StarterSTS
If you want to use Role-Based Administration, try Enterprise Library from Microsoft P&P, the ASP.net membership provider, or direct COM access to Authorization manager (formerly known as AzMan)
I prefer & use the claims-based approach:
Use ActiveDirectory + ADFS 2.0
(why not use the built in fault tolerance and replication of AD?, ADAM is a pain)
Silverlight Implementation of Ws-Trust as documented here:
http://www.leastprivilege.com/UsingSilverlightToAccessWIFSecuredWCFServices.aspx
Edgar, I'm also interested in any results you had, I am at the same place you were in.
Shoaib, I have looked at this but I think it is less desirable than using just the .config via ActiveDirectoryMembershipProvider, as then you are just using off the shelf components, not writing your own security system.
EDIT:
I hope this helps someone. I can't belive there is not a good example of this on the internet. It is simple enough. As I said before this is superior to using a custom authentication system.
Using AD LDS (ADAM) authentication with Silverlight compatible WCF calls (non wsHttp)
Client side:
1) Invocations from Silverlight look like this, this works if you are using the Channel Factory too.
var client = new MyWCFServiceClient();
client.GetPersonCompleted += client_GetPersonCompleted;
client.ClientCredentials.UserName.UserName = username;
client.ClientCredentials.UserName.Password = password;
client.GetPersonAsync();
2) return values from server will have an Error property if the login fails. If the user lookup fails, the error is something confusing like “at least one security token could not be validated”. Since your server side code is not able to re-wrap this (as it's all happening in the web.config) it is better for your client code to catch System.ServiceModel.Security.MessageSecurityException and interpret it as a login failure, or check the InnerException message to make sure it is the "security token" thing.
void client_GetPersonCompleted(object sender, GetPersonCompletedEventArgs e)
{
if (e.Error == null)
{
// do stuff with e.Result;
}
if (e.Error is MessageSecurityException)
{
// Your login did not work
}
}
Server side:
1) The WCF service class must have
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)] or Required
2) you have to set up your LDS instance with SSL enabled, which is tricky. See: h't't'p://erlend.oftedal.no/blog/?blogid=7
3) web config - need to:
Add the LDS connection string
Add ActiveDirectoryMembershipProvider
Add <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
change your custom binding to include <security authenticationMode="UserNameOverTransport"/> see http://msdn.microsoft.com/en-us/library/dd833059(VS.95).aspx
Example:
<configuration>
<connectionStrings>
<add name="ADConnectionString" connectionString="LDAP://myserver:[SSL port number]/[where your user are in LDS, in my case: ‘OU=ADAM Users,O=Microsoft,C=US’]" />
</connectionStrings>
<system.web>
<compilation debug="true" targetFramework="4.0" />
<membership defaultProvider="MyActiveDirectoryMembershipProvider">
<providers>
<add
name="MyActiveDirectoryMembershipProvider"
type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a"
connectionStringName="ADConnectionString"
connectionUsername="[domain]\[username]"
connectionPassword="[plain text windows password]"
connectionProtection="Secure"
/>
</providers>
</membership>
</system.web>
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
<behaviors>
<serviceBehaviors>
<behavior name="MyServiceBehaviour">
<serviceMetadata
httpsGetEnabled="true"
httpGetEnabled="false" />
<serviceDebug includeExceptionDetailInFaults="false" />
<serviceCredentials>
<userNameAuthentication
userNamePasswordValidationMode="MembershipProvider"
membershipProviderName="MyActiveDirectoryMembershipProvider"/>
</serviceCredentials>
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<customBinding>
<binding name="myCustomBinding">
<security authenticationMode="UserNameOverTransport"/>
<!-- <binaryMessageEncoding /> this is optional, but good for performance-->
<httpsTransport />
</binding>
</customBinding>
</bindings>
<services>
<service name="MessageBasedSecurity.Web.MyWCFService" behaviorConfiguration="MyServiceBehaviour">
<endpoint address="" binding="customBinding" bindingConfiguration="myCustomBinding"
contract="MessageBasedSecurity.Web.MyWCFService" />
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
</system.serviceModel>
</configuration>
I hope this helps someone. I welcome comments/improvements.
Related
I'm currently investigating WCF for implementing a RESTful service that will run through IIS.
Currently our software offers the ability to authenticate users against a range of sources
Our own internal user accounts stored in the database
A specified windows active directory where if authentication is
successful, a lookup is done to find which internal account the
winows one is linked to
Another LDAP server e.g Novell
So the way I want this to work is that a client sends an http(s) request with an
authentication header (basic for now) over SSL, then the service will use custom
authentication to implement the process described above.
For the moment I am self-hosting the service and trying to get the custom authentication
example working, it starts up correctly but all I get when I try to make a request from a browser
or a tool where i can attach an authentication header is
"Error 101 (net::ERR_CONNECTION_RESET): The connection was reset."
I have set a breakpoint in the custom authentication class an it is never reached, so I'm guessing its a problem with the
configuration.
My app.config;
<configuration>
...
<system.serviceModel>
<bindings>
<webHttpBinding>
<binding name="secure">
<security mode="Transport">
<transport clientCredentialType="Basic"></transport>
</security>
</binding>
</webHttpBinding>
</bindings>
<services>
<service name="CELCAT.RegisterMarker.RegisterMarker" behaviorConfiguration="myServiceBehavior">
<endpoint address="https://mymachine:8001/servicename"
binding="webHttpBinding"
bindingConfiguration="secure"
contract="myServiceContract" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="myServiceBehavior">
<serviceMetadata httpGetEnabled="True"/>
<serviceDebug includeExceptionDetailInFaults="True"/>
<serviceAuthorization serviceAuthorizationManagerType="MyServiceAuthorizationManager, authenticatonassembly" />
<serviceCredentials>
<userNameAuthentication userNamePasswordValidationMode="Custom"
customUserNamePasswordValidatorType="servicenamespace, serviceassembly" />
<serviceCertificate findValue="certname"
storeLocation="LocalMachine"
storeName="My"
x509FindType="FindBySubjectName" />
</serviceCredentials>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
</configuration>
I have read a post that said what I am trying to do is impossible out of the box with WCF
and to achieve this I will need to write a custom module or request interceptor as describe below;
authentication via custom module;
http://custombasicauth.codeplex.com/
authentication via request interceptor;
http://www.codeproject.com/KB/WCF/BasicAuthWCFRest.aspx
This seems like it should be possible to me, so my questions are
Is what i'm trying to do possible?
If so what have I got wrong? or if not which work around is best?
OK after much googling and prompting from Andrew Church (Thanks Andrew) I've figured this out.
The problem was although I had generated a certificate, I hadn't bound it to a port. Steps to help generate certificates and binding them can be found at;
http://www.codeproject.com/Articles/24027/SSL-with-Self-hosted-WCF-Service
This however asks you to use httpcfg, this tool doesn't exist on Windows Vista or 7 (my OS), so a further Google revealed this article;
http://msdn.microsoft.com/en-us/library/ms733791.aspx
Which tells me to use netsh, perfect! Well not quite, because this requires a parameter called appid, I didn't know where I could find this so a further search lead back here;
What appid should I use with netsh.exe?
So I followed all of the steps, commented out the certificate part of my app.config and hey presto I hit my break point in the custom config.
Hope this helps anyone else with the same problem
I am not sure whether this will work, but what I've done in the past is use a custom HTTP module. Our API uses access tokens, so we use the module to inspect headers for the presence of a token, if it doesn't exist we redirect to an Authentication endpoint in the api. The endpoint expects Basic authentication. Hope this helps.
I have enabled the ASP.Net authentication service, as recommended by msdn. I am then attempting to use the service via a console app or winforms app (by adding a service reference to my local WCF service). I am doing custom authentication and transport security (so I am handling the AuthenticationService.Authenticating event in my Global.asax which works fine).
The authentication itself works fine, but the proxy created by adding the Service Reference does not include the CookieContainer property. This is obviously a problem when I try to pass the cookie token to subsequent services which require authentication.
Also, in the following client code, the IsLoggedIn() returns false, I'm guessing this is related to no cookie container being present.
ServiceReference1.AuthenticationServiceClient client =
new ServiceReference1.AuthenticationServiceClient();
bool isLoggedIn = client.Login("test", "test", "", true); //returns TRUE
bool check = client.IsLoggedIn(); //returns FALSE
Here is my web.config on the service:
<configuration>
<system.web>
<compilation debug="true" targetFramework="4.0" />
</system.web>
<system.web.extensions>
<scripting>
<webServices>
<authenticationService enabled="true"
requireSSL = "false"/>
</webServices>
</scripting>
</system.web.extensions>
<system.serviceModel>
<services>
<service name="System.Web.ApplicationServices.AuthenticationService"
behaviorConfiguration="AuthenticationServiceTypeBehaviors">
<endpoint contract="System.Web.ApplicationServices.AuthenticationService"
binding="basicHttpBinding"
bindingConfiguration="userHttps"
bindingNamespace="http://asp.net/ApplicationServices/v200"/>
</service>
</services>
<bindings>
<basicHttpBinding>
<binding name="userHttps" allowCookies="true">
<!--<security mode="Transport" />-->
</binding>
</basicHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="AuthenticationServiceTypeBehaviors">
<serviceMetadata httpGetEnabled="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
</system.serviceModel>
</configuration>
EDIT: Something else I should add, I did a Fiddler session of the service calling the Login method, and the cookie is being set and sent back to the client. But what am I supposed to do with no CookieContainer?
When this option is enabled the client will make sure all cookies received from a given web
service are stored and properly sent on each subsequent request in a transparent fashion.
But there is a catch: the cookie is only handled in the conversation with one web service.
What if you need to send the same cookies to different web services?
If you need to send the same cookies to multiple services, read this article: http://megakemp.wordpress.com/2009/02/06/managing-shared-cookies-in-wcf/
You need to configure the binding to allow cookies.
<system.ServiceModel>
<bindings>
<basicHttpBinding allowCookies="true">
</bindings>
Apparently, when adding a Service Reference (.Net 3.5+) to a WCF service on a client, the proxy class derives from System.ServiceModel.ClientBase. This class does not have a CookieContainer property (because the ClientBase supports non-HTTP protocols that have no concept of cookies).
http://netpl.blogspot.com/2011/11/managing-cookies-in-wcf-client.html
I could add a Web Reference instead, which would use the .Net 2.0 proxy class (and has CookieContainer property exposed) http://msdn.microsoft.com/en-us/library/bb628649.aspx. But I will most likely revisit my approach entirely and use custom headers and service behaviors to accomplish my goal.
Another option is to access the cookie container for the underlying channel like this:
var cookieManager = client.InnerChannel.GetProperty<IHttpCookieContainerManager>();
cookieManager.CookieContainer.Add(new Cookie(....));
For the above manager to be present, you need to set AllowCookies to true, e.g.:
<system.ServiceModel>
<bindings>
<basicHttpBinding allowCookies="true">
</bindings>
We are trying to create a WCF service that is only accesible by specified windows groups.
How can this be configured in the server web.config and the client configuration?
Note: We want to be able to control the windows groups who are allowed access in the server web.config not in code. Also, we dont want/need SSL at all.
Ive googled around and then best examples I can find are all like this...
WCF Service, Windows Authentication
But that doesnt explain how to limit access only to a specific group or groups.
If this is intranet application you can use netTcpBinding:
<services>
<service name="YourService"
behaviorConfiguration="YourServiceBehavior">
<endpoint
binding="netTcpBinding"
bindingConfiguration="SecureTransportWindows"
contract="YourContract" />
</service>
</services>
<bindings>
<binding name="SecureTransportWindows">
<security mode="Transport">
<transport clientCredentialType="Windows" />
</security>
</binding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="YourServiceBehavior">
<serviceAuthorization principalPermissionMode="UseWindowsGroups" />
</behavior>
</serviceBehaviors>
</behaviours>
And then in service code you can demand windows role:
class YourService : YourContract
{
[PrincipalPermission(SecurityAction.Demand, Role="MYDOMAIN\Administrators")]
public string SecuredOperation(string name)
{
return "secured operation";
}
}
If you need to set it in config then you must implement custom authorization:
<behavior name="YourServiceBehavior">
<serviceAuthorization principalPermissionMode="Custom">
<authorizationPolicies>
<add policyType="YourCustomAuthorizationPolicy"/>
</authorizationPolicies>
</serviceAuthorization>
</behavior>
And in code implement IAuthorizationPolicy interface:
public class YourCustomAuthorizationPolicy : IAuthorizationPolicy
{
//you need to check msdn
}
Ok this is the solution we came up with. Although it does involve a code change (adding the AspNetCompatibilityRequirements attribute) we can now acheive configuration of the groups/roles in the web.config file rather than hardcoding.
There are a number of steps to this...
1) Add the aspNetCompatibilityEnabled attribute into the serviceHostingEnvironment element and set to true, e.g....
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
This tells the WCF service to running in ASP.NET Compatibility Mode and participate fully in the ASP.NET HTTP request lifecycle. See this MSDN article for full details.
2) In the WCF code add AspNetCompatibilityRequirements attribute to the service class as per the link above and as specified in this MSDN article...
<AspNetCompatibilityRequirements(RequirementsMode:=AspNetCompatibilityRequirementsMode.Allowed)>
3) Now we can add the usual ASP authorization element in to restrict access to the specified groups/users (without the settings (1) and (2) above, this would be ignored by WCF)...
<system.web>
<authorization>
<allow roles="MYDOMAIN\WCFAuthenticatedUsers" /> <-- allows access to users in this group
<deny users="*" /> <-- denies access to all other users
</authorization>
</system.web>
I have been using stackoverflow.com as a resource as a professional programmer for years now. I would say 8 out of 10 times when I search for something on google, I get pointed to a question and answer here, and I am always relieved when that happens, because I know I am about to find the information I need.
I have been pulling my hair out trying to figure (what I think to be) a simple problem out, concerning setting up a routing service using WCF technology. I have browsed through the questions with similar titles here, and I have consulted a great many resources (both actual books on the subject, as well as websites) trying to figure this out, to no avail.
In a nutshell, I want to setup a system with the following layout:
{client}<-basicHTTP->{portal/router}<-fullWCF-WS*->{end-point-services1..n}
client: gets service reference to portal, able to call functions at end-point service
portal/router: gets requests from client, and sends them on to end-point services in a multi-cast setup
end-point-services1..n: gets request from client, routed through portal, processes request to search for things, and either responds, or logs data in a database to be checked later
I am, 100%, able to get a routing service up and running. The most successful models I have been able to follow, were outlined in the "What's new in WCF4: exercises 8 & 9, content bridging & routing" (msdn.microsoft.com/en-us/gg465212) and "Hello World with the Routing Service" (msdn.microsoft.com/en-us/library/dd795218.aspx) But I have used bits and pieces from all of the sources I have consulted (listed below).
Basically, what is frustrating me, is that I want a client (a 3rd party) to be able to just add a web service reference to the portal service (or, worst case scenario, use the svcutil.exe method), and be done with setup on their part. With that reference, they will have references to all the functions/methods they would want to call in all scenarios. The models I have looked at that do this require 2 references, one to the actual service, and one to the router, and then force the client to specifically call the router in their setup. None of my other attempts to make this particular setup work, have worked.
Your help with this would be greatly appreciated.
Here is a simplified version of my working model that almost is doing what I want:
(note, all services are being hosted in IIS)
PORTAL SERVICE (and IIS Host)
Portal.svc:
<%# ServiceHost Service="System.ServiceModel.Routing.RoutingService, System.ServiceModel.Routing, version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" %>
Web.config:
<configuration>
<system.serviceModel>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
<bindings>
...
</bindings>
<client>
<endpoint address="http://searcher1/Searcher.svc/general" binding="basicHttpBinding" contract="*" name="regularSearchServiceEndpoint" />
<endpoint address="http://searcher2/Searcher.svc/general" binding="basicHttpBinding" contract="*" name="regularSearchServiceEndpoint2" />
</client>
<behaviors>
...
</behaviors>
<routing>
<filters>
<filter name="MatchAllFilter" filterType="MatchAll" />
</filters>
<filterTables>
<filterTable name="filterTable1">
<add filterName="MatchAllFilter" endpointName="regularSearchServiceEndpoint" backupList="backupList1" priority="0"/>
</filterTable>
</filterTables>
<backupLists>
<backupList name="backupList1">
<add endpointName="regularSearchServiceEndpoint2"/>
</backupList>
</backupLists>
</routing>
<services>
<service behaviorConfiguration="routingConfiguration" name="System.ServiceModel.Routing.RoutingService">
<endpoint address="general" binding="basicHttpBinding" name="routerEndpoint1" contract="System.ServiceModel.Routing.IRequestReplyRouter" />
</service>
</services>
</system.serviceModel>
</configuration>
SEARCH SERVICE
ISearch.cs:
namespace SearchService
{
[ServiceContract]
public interface ISearch
{
[OperationContract]
string Ping();
[OperationContract]
string searchByInput(string input);
}
}
App.config:
<configuration>
<!-- When deploying the service library project, the content of the config file must be added to the host's
app.config file. System.Configuration does not support config files for libraries. -->
<system.serviceModel>
<bindings>
<basicHttpBinding>
...
</basicHttpBinding>
<customBinding>
...
</customBinding>
</bindings>
<client>
...
</client>
<services>
<service name="SearchService.Search">
<endpoint address="general" binding="basicHttpBinding" contract="SearchService.ISearch" name="SearchService">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
<host>
<baseAddresses>
<add baseAddress="http://localhost:8732/Design_Time_Addresses/SearchService/Service1/"/>
</baseAddresses>
</host>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior>
<serviceMetadata httpGetEnabled="True"/>
<serviceDebug includeExceptionDetailInFaults="False"/>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
</configuration>
SEARCH SERVICE HOST
Search.svc:
<%# ServiceHost Service="SearchService.Search" %>
Web.config:
<configuration>
<system.serviceModel>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
<bindings>
<basicHttpBinding>
<!--copied over from SearchService.App.config-->
</basicHttpBinding>
<customBinding>
<!--copied over from SearchService.App.config-->
</customBinding>
</bindings>
<client>
<!--copied over from SearchService.App.config-->
</client>
<services>
...
</services>
<behaviors>
...
</behaviors>
</system.serviceModel>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
</system.webServer>
</configuration>
CLIENT (where it all goes wrong)
Only way I have been able to get it to do what I want, is to add a web service reference to the searcher service (named "remotehost"), and then manually add client endpoints to the app.config file for the router, and force the client code to use that, INSTEAD of the direct link it already has to the searcher
Main.cs:
namespace Client
{
public partial class Main : Form
{
remotehost.SearchClient proxy;
public Main()
{
InitializeComponent();
proxy = new remotehost.SearchClient("RouterService");//("BasicHttpBinding_ISearch")
}
private void button1_Click(object sender,EventArgs e)
{
string response = string.Empty;
//uses method exposed by the SearchService service
response = proxy.Ping();
MessageBox.Show("Response from remote service:\n" + response
"Ping Response",
MessageBoxButtons.OK,
MessageBoxIcon.Information);
}
}
}
App.config:
<configuration>
<system.serviceModel>
<bindings>
<basicHttpBinding>
...
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://searcher1/Searcher.svc/general" binding="basicHttpBinding" bindingConfiguration="SearchService" contract="remotehost.ISearch" name="SearchService" />
<!--I manually added this-->
<endpoint address="http://portal/Portal.svc/general" binding="basicHttpBinding" contract="remotehost.ISearch" name="RouterService" />
</client>
</system.serviceModel>
</configuration>
I want to emphasize, this all WORKS, but it doesn't work the WAY I want it to. I am fairly certain I can push/pull/cajole this into the elegant setup I am envisioning, but I can't seem to find a resource or guide that will walk me through it for the first time.
Help?
Sources I have consulted, before coming here:
Learning WCF: A Hands-on Guide, by Bustamante, Michele Leroux {978-0-5961-0162-6} (read cover to cover, and did all exercises)
Windows Communication Foundation 4: Step By Step {978-0-7356-4556-1} (focused on chapter 14: Discovering Services and Routing Messages)
msdn.microsoft.com/en-us/library/ms734712.aspx {WCF: Getting Started Tutorial}
msdn.microsoft.com/en-us/gg465212 {what's new in WCF4: exercises 8 & 9, content bridging & routing}
codeproject.com/Articles/146835/How-to-create-scalable-services-with-WCF-4-0-Route {How to create scalable services with WCF 4.0 Router and Discovery services}
msdn.microsoft.com/en-us/library/dd795218.aspx {Hello World with the Routing Service}
msdn.microsoft.com/en-us/library/ee517421.aspx {routing}
msdn.microsoft.com/en-us/library/ee517423.aspx {routing service overview}
msdn.microsoft.com/en-us/library/ee517418.aspx {routine service features}
msdn.microsoft.com/en-us/library/ee517422.aspx {routing intro}
msdn.microsoft.com/en-us/library/ee517420.aspx {routing contracts}
msdn.microsoft.com/en-us/library/bb332338.aspx {wcf routing}
msdn.microsoft.com/en-us/library/ms730158.aspx {more wcf routing}
msdn.microsoft.com/en-us/library/ee354381.aspx {more wcf routing}
dandcohen.wordpress.com/2010/03/02/wcf-4-routing-service-multicast-sample/ {WCF 4 Routing Service Multicast sample}
UPDATE: 2012-04-28:
I figured out a way to do what I wanted. It still isn't as elegant as I wanted, but it get the job done and has allowed me to move forward.
Basically, take the interface from the main service, and implement it in a new service, call it router or portal, or whatever. In the new router/portal service, add a new service reference to the main service.
Now, both services are using the same interface, and have the same signatures for all their methods, so you can then just give the portal/router service wsdl to the 3rd party client, and only allow your portal/router service to communicate with the main service.
Additionally, if you have more than one main service, you can use the portal/router service to decide which of the main services to send requests to, using multiple service references to them, and proxies to send the jobs onward. It works really well.
It is basically a manual front-end routing service, but the beauty is, the detailed work can be done in the main services on a threading model, while the gatekeeping work can be done at the portal/router, so only actual requests are sent to the main services, allowing them to only do work, and the portal services to decide how or if they get that work. The next step I want to add it automatic discovery of new services, but for now, manual configuration is working fine.
I can post the source code for what I came up with, if anyone wants to see it and requests it.
The fundamental problem is that the router knows nothing about the service contract that the service is using - it uses a universal contract (one which uses the Message type). Therefore, there is no way for the router to auto-generate the metadata for the client.
What you will need to do is provide the metadata yourself, maybe as a static WSDL document, with the correct addresses in it and point clients to this
I have MiniProfiler set up and working in my ASP.NET MVC app. My controllers make calls via WCF to a BLL which in turn talks to the database. I would like to see profiling from the WCF service alongside the existing profiling I see from the web app. Is it a case of making MiniProfiler a parameter in all service calls?
In a recent release of the MvcMiniProfiler they added WCF support (version 1.8 or greater). This is a 3 step process to get this working:
Add References
First add references to the MvcMiniprofiler and MvcMiniProfiler.WCF in your UI layer and WCF layer via nuget (or download the source and compile your own).
Setup WCF Host
Second, within the web.config of the service host you have to add the miniprofiler as an endpoint behavior. All of the config sections belong in "configuration/system.serviceModel".
<endpointBehaviors>
<behavior name="miniProfilerBehavior">
<wcfMiniProfilerBehavior />
</behavior>
</endpointBehaviors>
Then add the behavior extension (Note the version number needs to match your version of the MvcMiniProfiler.WCF):
<extensions>
<behaviorExtensions>
<add name="wcfMiniProfilerBehavior" type="MvcMiniProfiler.Wcf.WcfMiniProfilerBehavior, MvcMiniProfiler.Wcf, Version=1.8.0.0, Culture=neutral" />
</behaviorExtensions>
</extensions>
Then setup the endpoints to use the profiler behavior you setup:
<services>
<service behaviorConfiguration="BaseBehavior" name="BSI.Something">
<endpoint address="" behaviorConfiguration="miniProfilerBehavior" binding="basicHttpBinding" bindingConfiguration="http" contract="BSI.ISomething"/>
</service>
</services>
Depends on your setup but I had to add one more web.config setting to run all managed modules for all requests. This config is in the root "configuration" section:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
</system.webServer>
Setup WCF Client
Last, setup the wcf client to "turn on" the mvc profiler by doing much the same above.
Add the extension:
<extensions>
<behaviorExtensions>
<add name="wcfMiniProfilerBehavior" type="MvcMiniProfiler.Wcf.WcfMiniProfilerBehavior, MvcMiniProfiler.Wcf, Version=1.8.0.0, Culture=neutral" />
</behaviorExtensions>
</extensions>
Add a behavior:
<behaviors>
<endpointBehaviors>
<behavior name="wcfMiniProfilerBehavior">
<wcfMiniProfilerBehavior />
</behavior>
</endpointBehaviors>
</behaviors>
Setup the endpoints to use that behavior:
<client>
<endpoint address="http://something/Something.svc" behaviorConfiguration="wcfMiniProfilerBehavior"
binding="BasicHttpBinding" bindingConfiguration="BasicHttpBinding_HTTP"
contract="BSL.ISomething" name="BasicHttpBinding_ISomething" />
</client>
And you're done!
Side Note:
How does the MvcMiniProfiler actually work over WCF?
Basically the client behavior sets up a SOAP header that tells the wcf host to turn on the profiler. It passes that header along which is read by the endpoint behavior on the WCF host side. It then turns the profiler on in the host. Lastly when the WCF host is replying back to the client it stuffs all the profiler goodness into the SOAP response header which is in turn read by the WCF client. Pretty ingenious.
That's one method, but in order to get the reference to the libraries you would have to add references in the lower layers for MvcMiniProfiler anyway.
What I did in this very same situation is to take advantage of the global access point that MiniProfiler provides as a singleton. So, I just added the reference in the lower levels (deleted the stuff relative to MVC, such as the views) and just used MiniProfiler.Current as if I were on the upper layers.
It works like a charm. :)