Hi all,
I was impersonating the remoting DataPortal using the following configuration setting at the Windows Forms client:
<add key="CslaAuthentication" value="CSLA"/>
<add key="CslaAlwaysImpersonate" value="true"/>
and this setting at the remoting dataportal server:
<add key="CslaAuthentication" value="Windows"/>
However that didn't work, at the DataPortal server the custom csla identity that I had at the client was used instead of the Windows one. After debugging I fixed this changing the following code at DataPortal\Client\Dataportal.vb:
Private Function GetPrincipal() As System.Security.Principal.IPrincipal
If ApplicationContext.AuthenticationType = "Windows" Then
' Windows integrated security
Return Nothing
Else
....
TO:
Private Function GetPrincipal() As System.Security.Principal.IPrincipal
If ApplicationContext.AuthenticationType = "Windows" OrElse AlwaysImpersonate Then
' Windows integrated security
Return Nothing
Else
...
(AlwaysImpersonate is the same code declared at RemotingProxy)
Is this a bug or I'm doing something wrong here?
I also suggest that the AlwaysImpersonate value could be changed dynamically, maybe through the ApplicationContext
Regards
J.Amselem
Hi ajj3085
If that's true, what's the purpose of the CslaAlwaysImpersonate parameter ?
At RemotingProxy.vb there is this code (this is framework code, not modified by me):
If ApplicationContext.AuthenticationType = "Windows" OrElse AlwaysImpersonate Then
' make sure we pass the user's Windows credentials
' to the server
properties("useDefaultCredentials") = True
End If
So as far as I understand, the Windows credentials are being sended to the remoting DataPortal when either authentication is set to Windows or we're impersonating.
The CslaAlwaysImpersonate property exists so the Windows identity from the client can be used to authenticate with IIS through Remoting.
It has nothing to do with CSLA authentication at all!!
So your CSLA authentication mode must match on client and server like normal. In some cases however, people also want their client Windows identity to flow through to the server through Remoting. This is sometimes the case when the IIS server can't be configured to allow anonymous access, even though the application itself is designed to use custom auth.
Thanks for clarifying it , Rocky
What I was trying to do is to execute a managed process -Sql Server Integration Services (SSIS)- wich requires to be executed in the server (it requires the DLLs to be installed in the system, it's not a matter of permissions)
The process fails if I try to call it from the DataPortal with my custom identity but not if I call it with the Windows one, so I was trying to tweak the DP to use the Windows identity for this case.
I also tried succesfully calling SSIS from a web service (within a web service I can control the Windows identity loaded through the ASP.NET configuration), however it's more complex because I have to create, load and send the DTOs and with the remoting version I can load my BO's directly.
So if CslaAlwaysImpersonate is not useful for this, what do you recommend? Is there a way to "restore" the ASP.NET / Windows identity inside the dataportal so I can call SSIS ?
amselem:
So if CslaAlwaysImpersonate is not useful for this, what do you recommend? Is there a way to "restore" the ASP.NET / Windows identity inside the dataportal so I can call SSIS ?
You have to decide what user identity should be running the SSIS package.
Impersonating the client's Windows identity gives you a somewhat unpredictable identity under which to run SSIS (I would think). So perhaps it is best to directly impersonate a specific user account?
You can use a method on WindowsPrincipal (if I remember correctly) to force ASP.NET to temporarily run as a specific user. You need to provide the username/password to make that happen. This is a standard ASP.NET 2.0 capability.
It's at DataPortal\Client\DataPortal.vb
Private ReadOnly Property AlwaysImpersonate() As Boolean
Get
Dim result As Boolean = _
(ConfigurationManager.AppSettings("CslaAlwaysImpersonate") = "true")
Return result
End Get
End Property
I didn’t look just now, but it must be in RemotingProxy,
because this is a remoting-specific feature.
Rocky
From: ajj3085
[mailto:cslanet@lhotka.net]
Sent: Tuesday, July 17, 2007 12:40 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Bug impersonating the DataPortal
Do you mean RemotingProxy.vb (or .cs in my case)?
Because my Client\DataPortal.cs doesn't have that at all.
I'm using Csla 3.0.
ajj3085:
You're right , it's at the DataPortal\Client\RemotingProxy.vb. I had modified the Client\DataPortal.vb to do the trick but now I've removed that change.
Rocky:
I finally solved adding these lines to my DP_Fetch, now I use custom auth in both client and server but this code changes the identity to the Windows one, so I can execute SSIS:
AppDomain.CurrentDomain.SetPrincipalPolicy(System.Security.Principal.PrincipalPolicy.WindowsPrincipal)
Csla.ApplicationContext.User = _
I agree with ajj3085, I checked both sources vb and cs and they don't look for the same setting, this looks like a bug.
Yup, it is a bug. The C# code is wrong and so I’m fixing
it for 3.0.1 so it matches the VB “CslaAlwaysImpersonate” value.
Rocky
Copyright (c) Marimer LLC