Web services and security

[Smokey Grindle]

I want to make a security system in my webservice similar to the one that
reporting services uses it has a logon user and logoff user web method...
when you log on it logs you into a session and maintains your logged in
status until you log off or timeout... I dont want to have to pass
username/pass back and forth each time I call a method... I want to use
sessions and I need a custom authentication and authorization method for our
service (its how we defined it to work) how would you go about doing this?
In reporting services it uses a web service to do it in this order

Connect to web service with no IIS authentication
Log into Web service via a public webmethod called LogonUser
Webservice consumer has a cookier container and credentials set to
CrentialCache.DefaultNetworkCredentials

user logs on, all web methods now run as that user until user timesout or
calls LogOffUser

any ideas on how to do this? its basically like forms authentication just in
a web service and no login form... thanks!

 

[Cowboy \(Gregory A. Beamer\)]

A better option is to use WSE 3.0 (WS-Security). You can attach an 509
certificate, which will be more secure, and have less overhead, than adding
a session to the web service. It is also standards based, which allows you
to dupe the methodology for systems that have to be contacted from Java
(example).

 

[Smokey Grindle]

wouldnt each client require an X509 cert on their machine though?

 

[Cowboy \(Gregory A. Beamer\)]

Yes, but getting the cert can be part of the sign up procedure for the
application. This can be highly encapsuluated on a SmartClient application.
There are other, less secure, methods in WS-Security.

You can also generate keys for users after they have established a session
and pass that key (initially null) with each subsequent request. This will
require a custom authentication/session framework, but it is doable. I
currently use a key on one set of web services, but it was one that had to
be thrown up quickly, sits behind SSL and I control the clients (which are
other web apps on another domain), so I am not that worried about security.

As a slight alteration, you can send user login info every time and store
the current session completely on the backend. As this requires a user's
login, you will have to use SSL. If you are using a Smart Client and would
like to hide this, you can have them login via a web service and have it
return session token. If you use a custom method, you can keep the "session"
alive on the server side as long as you want. Just make sure it eventually
times out and the app logs it out when they shut it down. Do not trust users
to end session.