Re: Substituting new Context.User.Identity for Authentication in SPS 2003

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Fred LaForest (flaforest_at_community.nospam)
Date: 05/28/04 

Date: Fri, 28 May 2004 14:10:47 -0400

Thanks for the note. However, my inadequate skills at explaining my
questions have us talking on different subjects. Give me one more try to
get my message across.

Fact: MS SharePoint Portal Server does not perform authentication. It relys
on other agents to perform authentication tasks.
Fact: MS SPS does perform authorization based on a Windows account presented
when access is requested by a user.
Fact: MS SPS is based on .NET Framework, particularly ASP.NET for much of
it's functionality.
Fact: Since SPS is accessed via a browser, all currently supported
authentication methods rely on the IIS/browser combination to perform the
authentication.

SPS relys on IIS to perform authentication. IIS relys on the browser to
hold (or persist) identity
information between browser accesses, . The browser
either utilizes the Windows account of the user's own workstation (generally
not usefull for external clients) or it must popup an authentication dialog
box to query the user's identity. Once accepted, the browser caches the
identity information and presents this to IIS on each user request. IIS
then constructs a windows identity from the user's credentials,
authenticates that identity with the domain and, finally, submits the
request to SPS.

This arrangement requires no other software to be installed or developed.

There are a number of issues with relying on the browser (ANY browser, IE,
netscape, safari, etc, etc). One, only authentication methods involving just
the browser and IIS are supported. Two, the browser authentication popup
allows no customization (look and feel, branding, credible user help and
assistance, etc In short, it's ugly.)

I have an extranet situation where I must provide additional authentication
mechanisms. Each client can request the method of their choice for their
site collection. I also did not want the browser authentication popup
involved. In general, if you see the browser authentication popup, it means
th web site is having problems. I can't think of any commercial web site
that relys on the browser popup for authentication.

I decided to implement a secure authentication mechanism and identity
persistance mechanism which did NOT employ the browser's popup dialog box.
I also would be able to emply a wide range of authentication mechanisms
within this framework. (RSA SecurID, windows accounts, userid/password,
email addres/password, Passport, etc) I could configure the specific
authentication mechanism by site, by client company, by user. Very flexible
AND I could craft the user interface to be artistically consistent with the
main web site and include detailed help information. I wrote an HttpModule
to handle the identity substitution.

I could care less about ANY browser's authentication abilities. They are
all ugly. Forget about which browser is better (or supported) for
authentication. I want to rely only on the browser's ability to display
information. My mechanism would handle all authentication tasks.

SPS literature and documentation heralds, expounds, waxes poetic, and shouts
that it is based on .NET and ASP.NET. It states that users can easily
extend and customize SPS through its extensive (though incompletely
documented) object model.

Given these facts and statements, and a stack of .NET and ASP.NET articles,
books and examples, I made this one bad assumption.

THE BAD ASSUMPTION: Since SPS is based heavily on ASP.NET and since SPS
relys on other agents to authenticate users and to supply it a valid Windows
account with each request, I assumed that if I provided a properly built and
authenticated Windows Principal and Identity to ASP.NET, SPS would honor
that Identity. Why? Because SPS is an ASP.NET application and, according
to MSDN
literature, properly constructed ASP.NET apps all use the
Context.User.Identity to convey the user's account. Even the web.config
file includes the <identity impersonate=true /> and the
WindowsAuthentication HttpModule statements.

REAL WORLD: SPS does NOT seem to use the identity information in the ASP.NET
Context. It directly uses the account information supplied by IIS via the
"LOGON_USER" server variable. Since this variable cannot be change by the
time my HttpModule gets control, the entire mechanism is rendered useless.

Hence, we come back to my original question....

Does SPS use the ASP.NET Context.User.Identity? or the LOGON_USER variable?
What can I do to
make SPS use the ASP.NET Context.User.Identity? 

-- 
Fred LaForest
flaforest@statprobeinc.com (without the "inc")
"Wei-Dong XU [MSFT]" <v-wdxu@online.microsoft.com> wrote in message
news:g50KsFwPEHA.3664@cpmsftngxa10.phx.gbl...
> Hi Fred,
>
> Thank you for the replying!
>
> Your focus regarding this issue is whether other browser doesn't pop up
the authentication windows, so your web site will deny the access from
> these browsers. This issue is mainly related to two points:
> 1) the security system of SPS2003 is based on the windows security
architecture.
> The user account should be one windows local account or domain account so
that SPS can authenticate and authorize it. As we all know, the http
> protocal is one session-less protocal which maintains no state for the
user. So the browser should collect the user security credential information
> and  communicate with the server to authenticate the user. Then the
browser still needs to keep the security credential in the client side for
each
> request which tell the server that this user has been authenticated. In
this scenario, the security community is built under the co-operation of
> Client browser and the server side Windows OS.
>
> This is to say, if the browser doesn't provide this functionality to
authenticate the user and maintain the user credential and uses these info
to
> communicate with Windows server, this browser can't work smoothly with
Windows Web application based on windows security architecture. Due
> to this, some other browsers are not supported for communicating with
SPS2003.
>
> 2) some new feature of SPS2003 needs the support of Browser
> This article "About Web browser support for Web Part Pages" of
administrator guide lists two tables for us regarding the support info of
several
> Browsers.
>
> From the browser list supported by SPS2003, we can find that Netscape can
be used for Unix, Mac and Windows. I'd suggest you encourage  your
> users to use Netscape or IE for visiting SPS2003 so that the pop-up
authentication window will not be the problem for you.
>
> Furthermore, I think your suggestion on the custom authentication of
SPS2003 is a very cool profuct enhancement idea. I have forwarded it into
> our internal database which will be reviewed by our engineers. I have also
recorded your suggestion on supporting more browsers of SPS2003.
> Greatly appreciate your understanding and the wonderful suggestions!
Please feel free to let me know if you have any further question.
>
> Best Regards,
> Wei-Dong Xu
> Microsoft Product Support Services
> Get Secure! - www.microsoft.com/security
> This posting is provided "AS IS" with no warranties, and confers no
rights.
>

Relevant Pages

  • Re: access via login page rather than popup box
    ... If SPS was strictly intended to be an application used by Web browsers, ... browser, there's nothing there to receive the signon page. ... logon token will be compared to the Windows-compatible ACLs we put in SQL ... On the other hand, AD in Windows Server 2003 scales very, ...
    (microsoft.public.sharepoint.portalserver)
  • Re: Windows authentication in code
    ... With Windows auth, the browser actually ... If you aren't using Windows auth, the browser will not send authorization ... I guess that replicating Windows authentication ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: auto authenticate
    ... Microsoft has done away with sending credentials via URL, for security ... unless you are using a browser with no patches after say 2 ... You can however, try cookie authentication, where you check the cookie for a ... > file that is placed in the windows scheduler. ...
    (microsoft.public.inetserver.asp.general)
  • RE: Substituting new Context.User.Identity for Authentication in SPS 2003
    ... Your focus regarding this issue is whether other browser doesn't pop up the authentication windows, so your web site will deny the access from ... This article "About Web browser support for Web Part Pages" of administrator guide lists two tables for us regarding the support info of several ...
    (microsoft.public.sharepoint.portalserver.development)
  • Re: LOGON_USER lifetime using NTLM
    ... ASP.NET, i.e. Windows and Forms. ... Once the user logins using NTLM, ... issue a Form authentication cookie and then assume the user is logged through ... ASP.NET to issue 401 back to browser manually. ...
    (microsoft.public.inetserver.iis)