Hello,
Been developing an app for a few months now with a physical single tier mode and just now starting to try and get it to run in physical 3 tier mode. (Csla 3.8.3, .Net 3.5 SP1, Windows Server 2003 (IIS 6))
Windows Forms Smart Client
WCF DataPortal hosted in IIS 6.0
SQL Server
I was under the impression that this scenario would work out of the box with using the WcfDataPortalProxy, custom principal/identity object and custom authentication using Message based UserName credentials.
I believe i have everything configured properly on client and server (which was no small feat as the instructions from the 2008 book for getting a development self signed certificate were out of date or wrong)
I have implemented a custom principal and identity object according to the book.
I have implemented the PrincipalPolicy(IAuthorizationPolicy), and a CredentialValidator as described in chapter 21.
When I make my first call to CustomPrincipal.Login(username,password) I get back an exception that "The username is not provided.Specify the username in ClientCredentials"
A couple of questions:
First , is WCF supposed to be using my custom principal object as the credential for username message security, or is it a separate set of credentials?
Second, assuming they are separate credentials (which now that I think about it, they would need to be because WCF could never decrypt the serialized custom Csla principal for impersonation by Server.DataPortal)
a. Where does one assign those credentials?
b. We may ultimately have several customers hitting the same service. CredentialValidator simply takes a username and password. Is there a method where we can get additional information which would act as a customer identifier?
I will hold off on posting config info until it becomes absolutely necessary
Many Thanks,
Matthew
It sounds like you are trying to use username/password credentials at the WCF service level, not at the application level.
That is a whole thing unto itself.
The examples in the Using CSLA 4: Data Portal Configuration book cover application level authentication. I specifically didn't cover transport level authentication (like WCF service authentication) because that is a massive, complex topic and it has little or nothing to do with CSLA itself.
On the upside, I did cover how to do username/pw authentication at the WCF service level in the Using CSLA 3.0 ebook. It is tricky stuff, with numerous steps that must be done exactly right.
Honestly, you'd think it would be easier, but apparently the username/pw model just isn't something Microsoft views as mainstream, so they didn't make it easy...
Hi Rocky,
Thanks for the reply.
"On the upside, I did cover how to do username/pw authentication at the WCF service level in the Using CSLA 3.0 ebook. It is tricky stuff, with numerous steps that must be done exactly right."
I implemented everything in chapter 21 of you Expert C# 2008 Business objects. Is that the same material that is in your 3.0 ebook or is it different .
As I said, I think I have everything set up correctly, but don't understand how i pass credentials to the WCF service initialization.
I assumed that implementing a custom BusinessPrincipalBase and CallistoIdentity would do this for me automatically.
Thanks,
Matthew
The Principal stuff and the WCF stuff are totally separate from each other. Microsoft didn't make the WCF authn interact with Principal concepts at all.
ok so they are separate credentials.
Two Questions:
From a smart windows forms client how do I pass a username and password for WCF?
The app requires application level authentication and authorization only, and that the traffic between the client and application server be encrypted. Should I be using transport level security instead?
Thanks,
Matthew
The Principal stuff and the WCF stuff are totally separate from each other. Microsoft didn't make the WCF authn interact with Principal concepts at all.
Actually now that i read this again, I must be doing a poor job of using the correct language.
According to chapter 21 in your book, you can implement a custom WCF UserNamePasswordValidator and a custom WCF authorization policy. The code in the those implementations consume a class derived from Csla.BusinessPrincipalBase.
I am confused by your statement.
In _my_ implementation I chose to use the WCF transport credentials to load the server-side Principal object for each request. That was my choice in my implementation, because I thought that was a scenario that made sense.
The hard part was getting WCF to flow the credential through the network, because that required a cert, and some finicky configuration settings, along with a two-part processing step in the service. First, verify the pw, second, load the principal.
Because the typical csla approach does verify and principal create in one step, I added the principalcache concept as a short-term storage to avoid hitting the security db twice. By short-term I mean something like nanoseconds.
I can't say why your implementation isn't working. It took me hours of time, working with other experts to create the solution in the book, and it was VERY finicky in terms of configuration and getting that cert right...
Copyright (c) Marimer LLC