Re: lack of understanding of principals, identities, and context

From: Teemu Keiski (joteke_at_NOSPAMaspalliance.com)
Date: 08/20/03 

Date: Wed, 20 Aug 2003 16:49:48 +0300

It really concerns things when authenticating and/or authorizing are hard
customized and it isn't just Forms Authentication specific. In simple case I
don't see anything wrong with simple session solution but framework support
is one main thing why I'd avoid it.

Other thing when it is used would be when you use role-based authentication.
In that case you could let Forms Authentication to handle the authenticating
and store roles into the login cookie (UserData property of
FormsAuthenticationTicket). Then on Application_Authenticaterequest it is
checked if Request.IsAuthenticated=true (login cookie exists in case Forms
auth) and then roles read from cookie and again custom IPrincipal populated
with information regarding roles.

In case when cookies are not allowed, you still can use Forms Authentication
(I think I have explained it to you earlier). In that case the
FormsAuthenticationTicket is persisted in the Querystring, but the drawback
was with keeping this on every page so that login information is persisted
when user navigates on the site. But if you want to avoid this drawback,
getting to use cookieless sessions is one solution and that leads to the
solution you discussed about. 

-- 
Teemu Keiski
MCP,Designer/Developer
Mansoft tietotekniikka Oy
http://www.mansoft.fi
AspInsiders Member, www.aspinsiders.com
ASP.NET Forums Moderator, www.asp.net
AspAlliance Columnist, www.aspalliance.com
"Lauchlan M" <LMackinnon@Hotmail.com> kirjoitti viestissä
news:%23asS0TwZDHA.1280@tk2msftngp13.phx.gbl...
> > HttpContext is request specific (recreated for every request) and
> therefore
> > you'd need to set the user on every request that means creating instance
> of
> > FiveADayPrincipal and assigning it to the Context.User.
> >
> > Therefore there exists methods in Global.asax as
> > Application_AuthenticateRequest as they are called on every request and
> can
> > be used to set the Principal.
>
> So, if you are not using cookies, what is the best way to maintain state
> across a session? Do you set a session variable, say UserID, when the user
> logs in, and get the user information from this in the Global.asax
> Application_AuthenticateRequest each time to repopulate the context
object?
>
> If you've gone this far with rolling your own solution, why bother with
> setting the MS context authentication stuff on each Global.asax
> Application_AuthenticateRequest, but instead just check the filepath using
> HttpContext.Current.Server.MapPath() (or whatever else you need to
configure
> you authentication framework) and set roles and permissions accordingly in
> your own framework (eg session variables)?
>
> It would not be too heavy (only involving two or three session variables,
eg
> userID, role, and permissions).
>
> What would be the pros and cons of this approach?
>
> MS have not made their forms authentication framework intuitive at all
IMO.
>
> Lauchlan M
>
>

Relevant Pages

  • Re: Problem with Forms Authentication cookies
    ... > only 2, the ASP.NET_SessionID cookie and the Forms Authentication cookie, ... > The next request coming is is a GET request for the Forms Authentication ... > In looking at the logs for NORMAL expired authentication redirects these ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: Forms Authentication problem with WebRequest
    ... The normal request will go like this: ... handles login, redirects to page.aspx, passes a cookie or url variable ... reqests page.aspx and sends cookie back to server ... - authenticating has nothing to do with this scenario, but with server authentication. ...
    (microsoft.public.dotnet.framework)
  • RE: Forms authentication cookie handling question (C#)
    ... I also replaced all of my ticket authentication code with the ... // Username and or password not found in our database... ... LoginControl's default code logic to generate authentication cookie. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Problem with Forms Authentication
    ... Put a check to see if the request is authenticated (i.e. the authentication ... > not persist the authentication cookie beyond the session ... > the login page. ... > necessary session variables. ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: Problem with Forms Authentication
    ... >> not persist the authentication cookie beyond the ... >> the login page. ... >> session variables while I am making the database trip ...
    (microsoft.public.dotnet.framework.aspnet.security)