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

Discussion in 'ASP .Net' started by =?Utf-8?B?VHJldm9yIEFuZHJldw==?=, Dec 15, 2004.

  1. 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
     
    =?Utf-8?B?VHJldm9yIEFuZHJldw==?=, Dec 15, 2004
    #1
    1. Advertisements

  2. 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" <> wrote in message
    news:...
    > 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, Dec 15, 2004
    #2
    1. Advertisements

  3. Re: 3-Tier Web Application, forms authentication, persistence of u

    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" <> wrote in message
    > news:...
    > > 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

    >
    >
    >
     
    =?Utf-8?B?VHJldm9yIEFuZHJldw==?=, Dec 15, 2004
    #3
  4. Re: 3-Tier Web Application, forms authentication, persistence of u

    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" <> wrote in message
    news:...
    > 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" <> wrote in message
    > > news:...
    > > > 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, Dec 15, 2004
    #4
  5. Re: 3-Tier Web Application, forms authentication, persistence of u

    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" <> wrote in message
    > news:...
    > > 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" <> wrote in message
    > > > news:...
    > > > > 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
    > > >
    > > >
    > > >

    >
    >
    >
     
    =?Utf-8?B?VHJldm9yIEFuZHJldw==?=, Dec 15, 2004
    #5
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?TGFycnkgQ2hhcmx0b24=?=

    n-Tier/Layer with NULL and persistence

    =?Utf-8?B?TGFycnkgQ2hhcmx0b24=?=, Apr 8, 2006, in forum: ASP .Net
    Replies:
    3
    Views:
    468
    =?Utf-8?B?TGFycnkgQ2hhcmx0b24=?=
    Apr 9, 2006
  2. javaguy44
    Replies:
    10
    Views:
    1,043
    Michael Berg
    May 18, 2004
  3. Shantanu Bhattacharya
    Replies:
    2
    Views:
    628
    Christopher Benson-Manica
    Dec 26, 2003
  4. Shantanu Bhattacharya

    Converting a 2-tier application to 3-tier application

    Shantanu Bhattacharya, Dec 25, 2003, in forum: C Programming
    Replies:
    2
    Views:
    522
    Christopher Benson-Manica
    Dec 26, 2003
  5. Kenneth P. Turvey

    Java Persistence API and persistence.xml

    Kenneth P. Turvey, Mar 15, 2008, in forum: Java
    Replies:
    2
    Views:
    17,671
    Kenneth P. Turvey
    Mar 16, 2008
Loading...

Share This Page