Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm primarily a .NET desktop app programmer. Coming into the web world has been difficult. I'm trying to convert one of my Silverlight apps into HTML. But I'm having a hard time figuring out the authentication system. I'm trying to read up on Live ID authentication and Windows Authentication but I'm having a hard time putting it all together in my head. Perhaps you can help?

My App Framework

My client application is a TypeScript (javascript) HTML page (or pages). And the server is a WCF Data Services REST API hosted in ASP.NET. The service works with a SQL database.

The Problems (Claims Based)

When I look at something like Live ID authentication, it's known as claims-based authentication, right? So if I had this implemented correctly, someone comes to the website, I need to verify that they are logged in. How do I do that from a client-side HTML page? Do I have a recurring timer that is validating the login every 30 seconds or something? Or is that done server-side on each call to the service?

I know that if they aren't logged in, I need to send them to the live login page, once they log in, the live page will redirect them to my server with the authorization token in the query string (or something like this). At this point though, what do I do 5 minutes down the line when they make a call to the webservice for data? Is that token sent on every call to the server some how? How do I validate that when they call the service, it is actually them? Do I have to wrap every service call in a ValidateUser() method or something? I have a user ID in the database that I would have to match with their user token somehow.

The Problems (Windows Authentication)

The previous problem still exists here. How do I know that every call from the client is still them? Additionally though, I need to understand what do I do from the HTML side to the server side to authenticate them and then continue the authentication.

Conclusion

I cannot really find any sort of explanation that conceptually explains all of this information and gives me the big picture of how it all works. I'm really hoping someone here can fill in these gaps and give me a better idea on how to implement the client and server authentication.

Thanks!

Update

I found a great book that really explains a lot of this. It's entitled "A Guide to Claims-Based Identity and Access Control". It's part of the patterns & practices series.

Thanks to all for your answers and put me on the right track.

share|improve this question
    
Your second question is handled by sessions. You know its them because its their session, you already authenticated them, and until their session expires you know its them. Most of this information is in the documentations for both frameworks your wanting to use. –  Ramhound Jan 24 '13 at 17:18
add comment

2 Answers 2

up vote 3 down vote accepted

I would use sessions. You can store the information you need after they've logged in, be it a token given by the login service or even just an isLoggedIn boolean value.

Then, you can check in pages that need it (Inheriting from a base page class is great for this) that the information is there. If not, kick them back out.

So, in your code that processes the response from the claims-based auth (I do a lot of work with CAS and Shibboleth, two claims-based systems in heavy use in academia), you'd do something like :

if(isSuccessfulLogin)
{
    Session.Add("isLoggedIn",true);
    Session.Add("userId", userIDfromService);
}

Then, in your Page_Load method, you'd just do something like:

if(Session["isLoggedIn"])
{
    // do whatever
}
else
{
    // redirect somewhere
}

These are very simplified, and leave out the details.

share|improve this answer
    
You cannot really do this stuff in a client-side page served by the server, plain HTML and JS. You need to use something like ASP.NET that analyzes data during the request and then behaves differently for the response (like redirecting to logon if session is expired etc) There isn't really any client-side JS logic you can use do that stuff huh? –  Thraka Jan 24 '13 at 21:50
    
Well, you could try to use local storage, but I wouldn't put sensitive info in that. I must have missed the HTML and JS only part. I unfortunately don't know enough about WCF to know what's possible. –  Greg Bair Jan 28 '13 at 19:09
add comment

Take a look at http://www.asp.net/web-forms/videos/authentication. It seems like its geared towards a newcomer audience. (Yes, it says web-forms, but the information is applicable to a broader scope).

Asp.net already has libraries built in for the basics. You should look into RoleProvider and MembershipProvider.

Basically, you should authenticate each HTTP request. How you perform authentication and how you persist it is up to you. It's possible to store a cookie on the client, use a session, etc...

The definitive guide to forms based website authentication is a nice cross-platform list of do's and don'ts. Tons of info there, and once you're up and running, this will have a bunch of gotchas you may have missed.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.