views:

32

answers:

2

I need to create a single sign-on structure and my question is: is SSL a must?

Details: The application will have a link to my web application. When the user clicks that link, their local username will be passed to my web app at which point a look-up in a mapping file is done. If that local username exists in the map, then the user is logged in. If not, then the user will be prompted to enter their network username and password, and when authenticated, an entry in the map will be created.

How do I ensure that user is who they say they are and not Joe Blow from off the street sending in an HTTP POST request with that username?

Do I have to use SSL (and if so, what does that entail)? Would adding a salt and encrypting the username be sufficient? Maybe locking it down so the source IP has to be within a controlled range?

My web app runs on IIS 6/7 and uses the ASP.NET MVC framework, if that is important.

A: 

Sounds like a poor way of doing authentication since the user passes no secret to the webapp. Since it's on the intranet most likely I guess you could get away with using hashes of the username + salt as a session identifier. While not having used ASP.NET I'm sure it allows you to create sessions that never time out which is the route I'd go rather than reimplementing the wheel, unless of course updating the session IDs dynamically in the desktop application is an issue.

Novikov
A: 

Sounds like you want to utilise SSL client-side certificates. How you implement this depends on your setup.

Other info to bear in mind:

If I want to send 'dmoules' to your app, I can. You can't stop me doing that. You need to authenticate via a trusted source that provides proof of identity. You can't trust the HTTP requests to be from your application unmodified without some proof (such as a client-cert).

Rushyo