StrataFrame Forum
Home      Members   Calendar   Who's On
Welcome Guest ( Login | Register )
      



Identity ProblemExpand / Collapse
Author
Message
Posted 06/15/2007 4:45:13 AM
StrataFrame Beginner

StrataFrame BeginnerStrataFrame BeginnerStrataFrame BeginnerStrataFrame BeginnerStrataFrame BeginnerStrataFrame BeginnerStrataFrame BeginnerStrataFrame Beginner

Group: StrataFrame Users
Last Login: 08/30/2008 7:14:27 AM
Posts: 32, Visits: 107
Hi,

i got a webapp running under iis 6. its an intranet app that uses the following web.config settings to authenticate a user:

<authentication mode="Windows"/>

<identity impersonate="true"/>

This works fine for all my old manual CRUDs -> the user always gets identitied as its Windows Identity and since the Sql Server roles are linked to ntgroups they can perform the action based on the permissions set on the table/sp for the ntuser or ntgroup.

It also works when I use the Application Framework, but only with the Data Retrieval methods. If I perform an Insert/Update or Delete I always get an error that I am not allowed to access the Database. The reason for this is that the Application Framework ignores impersonation and runs under the standard account of the web app.

What do I have to do to get the Application Framework to use the right identity?

Post #9610
Posted 06/15/2007 9:43:49 AM


StrataFrame Developer

StrataFrame Developer

Group: StrataFrame Developers
Last Login: 10/21/2008 9:20:58 AM
Posts: 2,685, Visits: 1,887
Since the connection string is stored within the DbDataSourceItem and that DbDataSourceItem is in a shared variable that is shared across the AppDomain, there isn't a way to impersonate users within the connections used by the DbDataSourceItem.  One of our users did setup his web server to use a different DbDataSourceItem per user (they're stored in a collection by key).  When the user logs in, he programmatically created a connection string using the users supplied credentials and added that new DbDataSourceItem to the database with the key stored in a session variable.  When the business objects were instantiated, he pulled the key out of the session variable placed it in the DataSourceKey property of the business objects so that each BO used the connection associated with its user.


www.bungie.net
Post #9616
Posted 06/18/2007 3:13:54 AM
StrataFrame Beginner

StrataFrame BeginnerStrataFrame BeginnerStrataFrame BeginnerStrataFrame BeginnerStrataFrame BeginnerStrataFrame BeginnerStrataFrame BeginnerStrataFrame Beginner

Group: StrataFrame Users
Last Login: 08/30/2008 7:14:27 AM
Posts: 32, Visits: 107
Well, I dont think the connection string is the problem. Since i use Integrated Security one Connection String for all is enough.

My problem is that the identity of the current user is not retrieved correctly within the StrataFrame CRUD methodes. Like I said the right Windows Identity is used when i use the Data Retrieval Methods of the StrataFrame BO and that one uses the same DbDataSourceItem(or not?).  But when i use the StrataFrame BO-Methodes to Update, Create and Delete it uses the Networkservice - Account rather than the Users Account performing the request.

I found this article that might be helpful to figure out why impersonation fails

http://pluralsight.com/wiki/default.aspx/Keith.GuideBook.WhatIsImpersonation

Post #9635
Posted 06/18/2007 8:35:38 AM


StrataFrame Developer

StrataFrame Developer

Group: StrataFrame Developers
Last Login: 10/21/2008 9:20:58 AM
Posts: 2,685, Visits: 1,887
OK, it looks like there are a couple things that we can do to solve this problem.  First off, in 1.6.1, the DataLayer has been changed so that if the DataLayerSavingThreads property = 1, it does not spawn new threads.  Instead, it just uses the current thread (the one that called Save()).  The next thing is to save off the principal of the current thread and set the CurrentPrincipal on each thread that is created while saving.  So, looks like your problems will be fixed in 1.6.1.  The following link is to the latest DLLs that don't spawn new threads when that property = 1.  Put them on your server and let me know if it fixes the problem of saving.

http://forum.strataframe.net/FindPost9612.aspx


www.bungie.net
Post #9638
Posted 06/18/2007 9:33:00 AM
StrataFrame Beginner

StrataFrame BeginnerStrataFrame BeginnerStrataFrame BeginnerStrataFrame BeginnerStrataFrame BeginnerStrataFrame BeginnerStrataFrame BeginnerStrataFrame Beginner

Group: StrataFrame Users
Last Login: 08/30/2008 7:14:27 AM
Posts: 32, Visits: 107
Hi Ben,

thanks for your reply. In what Namespace/Class can i find that Property? I only found DataAccessLayerThreads but not DataLayerSavingThreads.

thanks

Post #9643
Posted 06/19/2007 1:09:48 AM
StrataFrame Beginner

StrataFrame BeginnerStrataFrame BeginnerStrataFrame BeginnerStrataFrame BeginnerStrataFrame BeginnerStrataFrame BeginnerStrataFrame BeginnerStrataFrame Beginner

Group: StrataFrame Users
Last Login: 08/30/2008 7:14:27 AM
Posts: 32, Visits: 107
Well, I tried it anyways since i thought the default value might well be 1. Guess I was lucky -> Now it works perfectly. Thanks a lot for your help!
Post #9646
Posted 06/19/2007 8:55:23 AM


StrataFrame Developer

StrataFrame Developer

Group: StrataFrame Developers
Last Login: Yesterday @ 5:04:58 PM
Posts: 4,780, Visits: 4,744
Glad you got it going
Post #9649
Posted 06/19/2007 8:56:17 AM


StrataFrame Developer

StrataFrame Developer

Group: StrataFrame Developers
Last Login: 10/21/2008 9:20:58 AM
Posts: 2,685, Visits: 1,887
Good   Like I said, we'll be changing the threads to use the same principal as the spawning thread in the next release.  Oh, you're right, it's DataAccessLayerThreads, not the other... and like you said, yes, the default value is already 1.


www.bungie.net
Post #9650
« Prev Topic | Next Topic »


Reading This TopicExpand / Collapse
Active Users: 0 (0 guests, 0 members, 0 anonymous members)
No members currently viewing this topic.
Forum Moderators: Ben Chase, Trent L. Taylor, Steve L. Taylor

PermissionsExpand / Collapse

All times are GMT -6:00, Time now is 6:26am

Powered by InstantForum.NET v4.1.4 © 2008
Execution: 0.063. 8 queries. Compression Enabled.
Site Map - Home - My Account - Forum - About Us - Contact Us - Try It - Buy It

Microsoft, Visual Studio, and the Visual Studio logo are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries.