Re: 3-Tier Web Application, forms authentication, persistence of u
From: Trevor Andrew (nntp_No_S.p.a.m._at_tassoc.com.au)
Date: 12/15/04
- Next message: Jeff Evans: "Re: good host for a small site"
- Previous message: CJ Taylor: "Attribute being escaped"
- In reply to: Kevin Spencer: "Re: 3-Tier Web Application, forms authentication, persistence of u"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 15 Dec 2004 15:45:02 -0800
Hi Kevin,
I'd actually prefer to avoid using Session. Although we will initially be
deploying on a single presentation tier server, we may move to a
load-balanced farm, which would mean using more complex means of session
management (SQL Server, state server etc), which I'd like to try and avoid if
possible.
I will keep that alternative in mind however.
Regards,
Trevor
"Kevin Spencer" wrote:
> Hi Trevor,
>
> Why don't you create a User class with the user information in it, and store
> it in Session?
>
> --
> HTH,
> Kevin Spencer
> ..Net Developer
> Microsoft MVP
> Neither a follower
> nor a lender be.
>
> "Trevor Andrew" <nntp_No_S.p.a.m.@tassoc.com.au> wrote in message
> news:9D2936D3-2B4B-4D11-99C1-C6F5D96D388E@microsoft.com...
> > Hi Kevin,
> >
> > Thanks for that ... the approach you're taking sounds good, but I guess my
> > main concern (which I perhaps didn't state quite clearly enough) is what
> is
> > the best way to "attach" the user's initially supplied user identifying
> > information (which must be subsequently provided on every middle tier API
> > call with the user session, in a secure and encrypted way.
> >
> > Having thought about it further, I suspect that simply adding this
> > information securely encrypted as the "userdata" part of the Forms
> > Authentication ticket is probably an OK solution. I just wanted to get
> > other's ideas on how they have approached.
> >
> > The slightly odd part of this scenario is that the identifying information
> > doesn't correlate to a Windows user, or a database user, but to a user
> only
> > my middle tier API can validate (via a web services call from my
> presentation
> > tier), and it needs to be attached to each API call.
> >
> > Thanks for your help.
> >
> > Regards,
> > Trevor Andrew
> >
> > "Kevin Spencer" wrote:
> >
> > > Web Services are not totally stateless. Application, Cache, and Session
> are
> > > all available with Web Services. For example, we have a Web Service that
> has
> > > persistent objects stored in Cache on a per-client basis, persisting
> each
> > > client's data in the Cache, as it is expensive to initialize the user
> data.
> > > We use the Cache because we have more control over it. Each WebMethod
> takes
> > > an ID as a parameter, to identify the item in the Cache to which the
> request
> > > pertains.
> > >
> > > --
> > > HTH,
> > > Kevin Spencer
> > > ..Net Developer
> > > Microsoft MVP
> > > Neither a follower
> > > nor a lender be.
> > >
> > > "Trevor Andrew" <nntp_No_S.p.a.m.@tassoc.com.au> wrote in message
> > > news:452D38CE-2295-4B7C-B9A1-29D9ABFCD250@microsoft.com...
> > > > Hi There,
> > > >
> > > > Hopefully this isn't too difficult a question to express here. I have
> a 3
> > > > tier application.
> > > >
> > > > 1. Presentation Tier: ASP.NET web application. 2. Middle Tier: ASP.NET
> Web
> > > > Services that invoke COM based API for a third party product. 3. Data
> > > Tier: A
> > > > SQL Server database that I can only access via the API.
> > > >
> > > > The user authentication for the web application is actually done via a
> > > call
> > > > to the COM API. After successfully authenticating a user, where user
> > > details
> > > > have been collected via Forms Authentication, I propose to persist in
> > > > encrypted form within the Forms Authentication ticket the User Id and
> > > > Password originally provided by the end user to use on subsequent API
> > > calls
> > > > by that session.
> > > >
> > > > I guess this means that a) The Presentation Tier does require session
> > > state
> > > > to be maintained. b) The middle tier web services are totally
> stateless.
> > > c)
> > > > The encrypted User ID and Password are stored within the cookies
> > > collection.
> > > >
> > > > Any comments on this approach? Obviously we will be using HTTPS so at
> no
> > > > time do the credentials pass in clear text, but I'm still not that
> happy
> > > > about this encrypted User ID and Password being held in the browser's
> > > cookie
> > > > collection.
> > > >
> > > > Another alternative I've thought through is only temporarly storing
> the
> > > User
> > > > ID and Password in the Authentication ticket. I would then, in the
> > > > Application_Authenticate method in Global.asax, create an object that
> > > > inherits from the GenericIdentity object, and provide extra properties
> to
> > > > contain the Application User ID and Password, and use this object as
> the
> > > > Identity under which the application is running. In this way, I could
> > > remove
> > > > the User ID and Password (encrypted though they are) from the cookies
> > > > collection, and maintain them within the HTTPApplication context.
> > > >
> > > > Any advice on either of these approachs would be most appreciated.
> > > >
> > > > Regards,
> > > > Trevor Andrew
> > >
> > >
> > >
>
>
>
- Next message: Jeff Evans: "Re: good host for a small site"
- Previous message: CJ Taylor: "Attribute being escaped"
- In reply to: Kevin Spencer: "Re: 3-Tier Web Application, forms authentication, persistence of u"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
