Architecture Decisions For Silverlight and MSSQL
Posted on 2008-06-17
I am trying to understand the appropriate architecture decisions and options for a new application to be developed in Silverlight with SQLServer as the back end database.
The Application will be distributed to all and Sundry who wish to use the application and the users data will be hosted in a secure centralised location. The users are standard Internet users like you and me who use the Internet for something different everyday.
The application will run in Silverlight in the clients web browser.
I am considering using Web Services to allow the client to communicate directly with the SQL Server however the thought of having SQL Server Web Services (SODA/Native HTTP SOAP Access) directly accessible from the Internet really scares the heck out of me, not to mention I do not understand how the authentication would work.
It seems to me that if I can work out the authentication and authorisation I can just do:
<Silverlight> <--Internet--FW--> [<MS SQL Native Web Services><SQL Server>]
(FW = Firewall)
But this seems really stupid, as I do security for a living and the thought of putting my SQL Server on the Internet (port 443/80 or otherwise only) seems pretty stupid...
So the other option seems to be:
<Silverlight> <--Internet--FW--> [<IIS><ASP.NET Web Service>] <---Local LAN--FW--> [<MS SQL Native Web Services><SQL Server>]
Of course this now seems like a whole lot more work for very little gain....
I guess that the Silverlight Client will have to pass in a "username and password" with every Web Service Request which the ASP.NET server will verify via a web-service against the SQL Server and will then pass the request off to the SQL Server using impersonation.
The idea is that all the logic will be in the SQL Server, if something can not be done using a TransactSQL it will be done using a C# CLR, so the ASP.NET Service will merely be a pass-though proxy with some initial authentication for the username and password of the user.