lack of understanding of principals, identities, and context

[Teemu Keiski]

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.

--
Teemu Keiski
MCP,Designer/Developer
Mansoft tietotekniikka Oy
[url]http://www.mansoft.fi[/url]

AspInsiders Member, [url]www.aspinsiders.com[/url]
ASP.NET Forums Moderator, [url]www.asp.net[/url]
AspAlliance Columnist, [url]www.aspalliance.com[/url]


"Bryan Ax" <bax@kleinbuendel.com> kirjoitti viestissä
news:7aa793c0.0308191246.38e44793@posting.google.c om...

> Currently, on a login page, I'm doing the following after validating
> login information:
>
> //user is a custom object we have.
> //FiveADayPrincipal is a class that implements the IPrincipal
> interface, and extends it for some additional functionality.
>
> Context.User = new FiveADayPrincipal(user);
> this.Response.Redirect("default.aspx");
>
> Now, on the default.aspx page, I do the following:
>
> private void Page_Load(object sender, System.EventArgs e)
> {
> //check to make sure user is logged in.
> bool auth = Context.User.Identity.IsAuthenticated;
>
> string name = this.Context.User.Identity.Name;
>
> if (! this.Context.User.Identity.IsAuthenticated)
> {
> this.Response.Redirect("/Login.aspx");
> }
> }
>
> I'm testing the results with those first two lines, and finding that
> the user is not authenticated. However, when I change the line
> this.Response.Redirect("default.aspx") to use this.Server.Transfer
> instead, it works fine. Does the context get lost when using
> redirects? I know people have said to use Server.Transfer for various
> reasons, but I have a bunch of legacy code using Response.Redirect. In
> order to protect security, am I going to need to change all those to
> Server.Transfer to keep the Context alive? Or should I just avoid
> using the Context.User.Identity.IsAuthenticated and instead test for
> some type of session object that stores my custom user (currently, the
> user is encapsulated in the custom Identity object)?
>
> Sincerely,
>
> Bryan Ax

[Lauchlan M]

> 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

[Teemu Keiski]

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
[url]http://www.mansoft.fi[/url]

AspInsiders Member, [url]www.aspinsiders.com[/url]
ASP.NET Forums Moderator, [url]www.asp.net[/url]
AspAlliance Columnist, [url]www.aspalliance.com[/url]


"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
>
>

[Bryan Ax]

From a performance perspective, which is going to be more efficient -
custom session variables, or recreating an authentication ticket on
every Application_AuthenticateRequest?

There is no other way to maintain a principal and identity without
doing it every request, huh? Bummer.


"Teemu Keiski" <joteke@NOSPAMaspalliance.com> wrote in message news:<#jqC#GyZDHA.1280@tk2msftngp13.phx.gbl>...

> 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
> [url]http://www.mansoft.fi[/url]
>
> AspInsiders Member, [url]www.aspinsiders.com[/url]
> ASP.NET Forums Moderator, [url]www.asp.net[/url]
> AspAlliance Columnist, [url]www.aspalliance.com[/url]
>
>
> "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
> >
> >

[Bryan Ax]

Hold on - one more thing...

If I login a user, then create an identity object, then do this...

FormsAuthentication.SetAuthCookie(myUserObject.Use rName, false);

will that make it so they remain logged in, and I don't need to check
and recreate it in Application_AuthenticateRequest? It appears so, but
before I go too much further, I wanted to ask people smarter than me.


[email]bax@kleinbuendel.com[/email] (Bryan Ax) wrote in message news:<7aa793c0.0308210639.344d496e@posting.google. com>...

> From a performance perspective, which is going to be more efficient -
> custom session variables, or recreating an authentication ticket on
> every Application_AuthenticateRequest?
>
> There is no other way to maintain a principal and identity without
> doing it every request, huh? Bummer.
>
>
> "Teemu Keiski" <joteke@NOSPAMaspalliance.com> wrote in message news:<#jqC#GyZDHA.1280@tk2msftngp13.phx.gbl>...

> > 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
> > [url]http://www.mansoft.fi[/url]
> >
> > AspInsiders Member, [url]www.aspinsiders.com[/url]
> > ASP.NET Forums Moderator, [url]www.asp.net[/url]
> > AspAlliance Columnist, [url]www.aspalliance.com[/url]
> >
> >
> > "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
> > >
> > >