I have a lot to learn about security, and had difficulty wading through all of the levels and options, so I devised my own programmatic solution.
When a user logs in from the Flex app (md5 hash on the password), I create a sessionId, store it in a hashtable in the .net app, and pass it back to the Flex app. The Flex app sends this token with each call. The server checks the passed in session id and compares the timestamp to the current time. If it is within the timeout period specified, it updates the timestamp and authorizes the call. If authorization fails, the user must log in again. I am certainly open to a better approach. Tracy Spratt, Lariat Services, development services available _____ From: [email protected] [mailto:[email protected]] On Behalf Of variableop Sent: Friday, April 03, 2009 4:07 PM To: [email protected] Subject: [flexcoders] Newbie SOA question I would like to provide a solution to maintaining login state over multiple calls to my .NET web service layer. So basically, the user logs in, then stores a login "token" internally on the Flex side so that each web service call can be authenticated as being made by someone who has already "logged in" to the system. Does anyone have any ideas on how to approach this? My initial approach was to cache the user's username/password and authenticate on each web service call (Direct Authentication). I was told, for obvious reasons, that this is insecure method and requires database hit each call. I am trying to implement WSE 3.0 enabled web services on the .NET side. Is this an SSO problem, or should I be using STS/Brokered Authentication approach? We just started our upgrade to VS2008, so maybe I should just pursue WCF methods instead? Any experiences with this would be greatly appreciated. TIA, variable
