I want to keep the Csla authentication PTracker currently uses but optionally use Windows authentication and Csla authorization as follows:
Windows authentication - the application believes in the user identity that it gets from Windows and doesn't (re)check for the user password.
Csla authorization - the application uses the user roles as specifyed in the Roles table of Security database.
Possible uses:
Full application server
- The user won't have access to the SQL Server.
- The solution will use an aplication server and Remoting.
- The user must be logged on the same domain of the application server.
SQL Server (with no application server)
- If the user has access to the SQL Server, Windows autehtication will also work as expected.
N.B. - On both scenarios, no domain checks are made for SQL Server access (i.e. it can be on a different domain).
"Not logged in domain" use case
When I go to a customer, I use my laptop and I'm not logged in the customer's domain. I must use an "admin" user of the application.
If the Windows domain\identity is unknown to PTracker, it shows the login window.
1. Application version and VS2008
1.1. Use version 3.0.5 of the application (and of Csla framework as well)
1.2. Convert it to VS2008
2. Backup
2.1, Make a backup of "ProjectTracker.Library\Security" folder
2.2. Make a backup of "MainForm.cs" file
3. Update PTracker
3.1. Unzip the attached file "PTrackerWindowsAuthenticationV01.zip" on top of your "ProjectTrackercs" folder
3.2. Open the solution under VS2008
3.3. Select "ProjectTracker.Library" project
3.4. Click "Show All Files"
3.5. Unfold "Security"
3.6. Select "NetworkInformation.cs" and "PTUser.cs"
3.7. Right-click those files and select "Include In Project" (don't forget to click "Show All Files" again)
4. Test new files
4.1. Rebuild the solution and test application login works as it did before the update
4.2. Select "PTwin" project and edit "App.config"
4.3. Change <add key="CslaAuthentication" value="Csla" /> to <add key="CslaAuthentication" value="Windows" /> and rebuild the project
4.4. If you are using a full application server, make the same change in "Web.config" of "...\RemotingHost\", build this Web Site and publish it again
4.5. Use a Windows login that is in the "Users" table of the "Security" database - PTracker shouldn't show the login window and you should have the correct configured roles
4.6. Use a Windows login that is NOT in the "Users" table - PTracker SHOULD show the login window and behave as it did before the update
4.7. You can revert step 4.3 in order to use the old Csla authentication.
5. Why "NetworkInformation.cs"?
This is used to find out the domain name and the joined status (is it an AD domain or a Workgoup or what?)
"PTPrincipal.cs" uses it in order to store the joined status and domain name in ApplicationContext.ClientContext["LocalStatus"]and in ApplicationContext.ClientContext["LocalDomain"]respectively.
"PTIdentity.cs" uses it in private void DataPortal_Fetch(LoadOnlyCriteria criteria) when trying to to Windows authentication, as it must compare the status and domain of the application server with those of the user.
"PTUser.cs" also uses it.
N.B. - Read the copyleft notice.
6. Why "PTUser.cs"?
Information about the user is scattered around in a bunch a different namespaces. This is a way to put it together in a single static object. "MainForm.cs" uses it to display some appropriate datails when authetication fails.
7. I don't need/want the "Not logged in domain" use case
This means when Windows authenticaton is used no Csla authentication is allowed
7.1. In "PTPrincipal.cs", go to public static bool Login(string username, string password) and follow the instructions
7.2. In "MainForm.cs", got to private void DoLoginWindows() and follow the instructions near "// now ask for login/password"
--
Tiago Freitas Leal
There are 2 cases where PTWin can't login automatically:
A) The Windows authentication is valid (same joined status and domain name) but the user isn't in PTracker Security table
B) The Windows authentication isn't valid because the user isn't authenticated on the same domain of the Application Server
The updated PTIdentity throws an exception to tell MainForm when B) happens.
If you get a System.Runtime.Remoting.RemotingException, on the application server the IIS configuration of the RemotingHost needs to be changed. (Note - In that configuration, all DataPortal exceptions will show up as RemotingException)
In order MainForm can get to the base exception, edit the Web.config file of the RemotingHost, go to the bottom of the file and just above the line
</system.web>
add a new line
<customErrors mode="Off" />
and "Publish Web Site" again.
Tiago,
I made the above changes to the latest version of ProjectTrackercs (CSLA v3.82.0) and I get the following error ("The name Database does not exist in the current context") in PTPrincipal.cs and also in PTIdenity.cs in the following code:
using (var cn = new SqlConnection(Database.SecurityConnection))
What is the reference to “Database”? I added using ProjectTracker.DalLinq ,but then I get the error "'ProjectTracker.Dalinq' does not contain a definition for 'SecurityConnection'". Is 'SecurityConnection' a reference to a stored procedure or something in the config file?
Dennis
Tiago,
I made the above changes to the latest version of ProjectTrackercs (CSLA v3.82.0) and I get the following error ("The name Database does not exist in the current context") in PTPrincipal.cs and also in PTIdenity.cs in the following code:
using (var cn = new SqlConnection(Database.SecurityConnection))
What is the reference to “Database”? I added using ProjectTracker.DalLinq ,but then I get the error "'ProjectTracker.Dalinq' does not contain a definition for 'SecurityConnection'". Is 'SecurityConnection' a reference to a stored procedure or something in the config file?
Dennis
Yes it is. SecurityConnection is a connection string that is read from app settings section of app.config file.
Copyright (c) Marimer LLC