3-Tier Web Application, forms authentication, persistence of user

[Guest]

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

 

[Kevin Spencer]

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.

 

[Guest]

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]

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.

 

[Guest]

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