I have a question about how to implement a security layer with the CSLA Data Portal Service and Silverlight.
I am using VS2010 and .NET 4.0, with a WCF service named CSLADataPortalService which is using the CSLA server side library along with all my server side binaries that are invoked from silverlight based client side libraries including CSLA light. This works fine as is but is lacking any kind of security layer.
I have currently developed a seperate secure WCF service using MessageHeaders as a way to validate credentials I am passing to it. This has been done in this manner as we have SSL offloaders that would not allow UserNameOverTransport to work correctly (even after trying the new .NET 4.0 "AllowInSecureTransport" enabled). What I ended up doing is implementing custom attributes for each method in the service. These attributes would then call a validation method to validate the message header credentials and then if successful continue to call the intended service method. This achieves the same UserNameOverTransport functionality without the binding issues with the SSL offloader.
I am looking to implement this same type of security to the CSLADataPortal service as it will sit behind an SSL offloader, but feel that the only way to actually get it to work would be by modifying the CSLA library to have the attributes as mentioned above for the Create/Fetch/Update/Delete methods of the DataPortal.
I suspect it will take creating my own custom data portal class inheriting from core code and then adding attributes to the CRUD methods above, then modifying our class templates to use this new portal class.
What are you suggestions for accomplish this?
Thank you,
Martin
You are correct, if you want to add extra WCF transport security you'll need to create your own proxy and host classes - which is typically done by subclassing WcfProxy on the client and WcfPortal on the server.
In extreme cases you might need to create your own proxy/host pair from scratch, in which case you can use WcfProxy and WcfPortal as a guide for your implementation. But even in this case there should be no need to alter CSLA itself, since the data portal is entirely interface-based and it uses a pluggable provider model for these components.
Copyright (c) Marimer LLC