Total Confusion! - ACLs and Windows authentication with no impersonation

[Pete Beech]

Hi all,
apologies if this has come up before, but I've been searching the
whole day and found nothing...

If I have authentication set to "windows", and identity
impersonation="false", do I need to grant access to the authenticated
windows user on the website and its resources (aspx files, etc)?

The MSDN VS.NET documention has the diagram in this link
(http://msdn.microsoft.com/library/d...ry/en-us/cpguide/html/cpconaspnetdataflow.asp)
- it looks like, if impersonation is set to false, it says it does
'other security checks', but does not go through NTFS ACL security.
Other responses I've seen say that, if impersonation is false, then
you only need to grant access to the ASPNET user.


However, in the Building Secure ASP.NET application book, Chapter 8,
it states "Windows ACLs
Client Requested Resources. The ASP.NET FileAuthorizationModule
performs access checks for requested file types that are mapped to the
ASP.NET ISAPI. It uses the original caller's access token and ACL
attached to requested resources in order to perform access checks.
**** Impersonation is not required. ****"

and later on, about Windows authentication,
"The access token of the authenticated caller (which may be the
Anonymous Internet user account if IIS is configured for Anonymous
authentication) is made available to the ASP.NET application. Note the
following:

This allows the ASP.NET FileAuthorizationModule to perform access
checks against requested ASP.NET files using the original caller's
access token.
Important ASP.NET File authorization only performs access checks
against file types that are mapped to Aspnet_isapi.dll.
*** File authorization does not require impersonation. **** With
impersonation enabled any resource access performed by your
application uses the impersonated caller's identity. In this event,
ensure that the ACLs attached to resources contain an Access Control
Entry (ACE) that grants at least read access to the original caller's
identity."


When I actually try it out, it seems that I do need to have the user
granted access with an ACL on the resource, even with no
impersonation. But this seems to directly contradict the .NET
documentation.

Does this really mean that, if I want to programmatically deny access
or use the authorization tag in the web.config, that I need to set
access to 'Everyone'? Can I really not just grant access to the ASPNET
account? Or am I just misunderstanding this completely?

What I would like is to be able to just grant access to ASPNET, but
still obtain the Windows User identity to do my own custom
authorization. Is this possible?

Hope someone can help me!,

Cheers,
Pete

 

[Raterus]

Here is how I think of this process.

You have aspx pages..and you have the resources this page wants to get at. When anonymous authentication is disabled, yes the page itself MUST have NTFS permissions set so the user can access the page, this is an IIS thing, you aren't even at ASP.NET yet at this step.

After they have access to the page, if impersonation is disabled, this is when the aspnet user takes over the process, and access to other resourses is granted based on that, not the original user.

You should be able to do what you are after, in your asp.net pages, use HttpContext.Current.User to get at the user who requested the page.

Hope this helps,
--Michael

 

[Pete Beech]

Hi,
thanks for the reply. However, I thought it was a bit different.. as I
understand it, if its a resource mapped to aspnet_isapi.dll, then IIS just
authenticates, and passes the token to the aspnet_wp.exe process. In the
diagram in the link I gave, its in the ASP.NET part that the NTFS
permissions are checked, and not in IIS.

It seems like this FileAuthorizationModule in ASP.NET is checking the NTFS
settings using the original callers token, and not the using the ASPNET
account - regardless of the impersonation settings. If I understand it
right, the impersonation settings only affect programmatic access to
resources (e.g. the example I saw in this article (link below) was the
loading of an XML file, from code - if impersonation was on, then the XML
would be only loaded if the impersonated user had access, if impersonation
was off, then it would be loaded if ASPNET had access).


So, I have the situation where, on the intranet, I want to programmatically
check the Windows User trying to logon against a DB, but without having to
grant specific access to anyone at the NTFS ACL level, apart from ASPNET -
but it looks to be me like I need to grant access to 'Everyone' just to be
able to get to ASP.NET to be able to do the programmatic authentication,
because of the FileAuthorizationModule.

I'm sure there is a way, but I can't see it..

Cheers, and thanks for your help..
Pete


(There is a great article about all this stuff.. which stresses the fact
that ACL checks are made, regardless of the impersonation settings:
http://msdn.microsoft.com/msdnmag/issues/02/04/ASPSec/ . And, to me, this
seems to directly contradict the .NET documentation (specifically this
diagram, and the statement "Notice that if impersonation is not enabled, the
application runs with the IIS process identity. For Microsoft Windows 2000
Server and Windows XP, the default identity is a User account named ASPNET
that is created automatically when ASP.NET is installed. If you want to
restrict access, you must use some other means of authorization, such as URL
authorization.") )

------------------------------------------
Here is how I think of this process.

You have aspx pages..and you have the resources this page wants to get at.
When anonymous authentication is disabled, yes the page itself MUST have
NTFS permissions set so the user can access the page, this is an IIS thing,
you aren't even at ASP.NET yet at this step.

After they have access to the page, if impersonation is disabled, this is
when the aspnet user takes over the process, and access to other resourses
is granted based on that, not the original user.

You should be able to do what you are after, in your asp.net pages, use
HttpContext.Current.User to get at the user who requested the page.

Hope this helps,
--Michael