Curious about security architecture in TaskVision
I am fairly new to web services security. I learned a lot from the authenticationTicket method used in Task Vision and have even started plugging it in to a pre-existing Windows Forms Client/ Web Services Data provider app that I deployed a few months ago with lame security!
I wonder (and forgive me if I missed this in the documentation) about the difference between a) using the ticket with reauthentication when the ticket times out and b) the method of sending a UserNameToken to the webservice on every single call and c) other methods that I don't know yet.
All I could think of was the possiblity of trying to cut down on precious extra round trips from the web server to the database server. So if one client hits the webmethod 10 times in 2 minutes, then that is 10 less trips to the db server just for the sake of authenticating the user. This makes sense in a data intensive application.
But that is only my own interpretation.
I believe, from reading on MSDN, that one of the problems with WS-Security is that there is no prescribed methodology for implementing it and that is one of the many issues that were targetted when putting together GXA/WS SKD/WSE.
So can someone explain to me why AuthenticationTickets was the way to go over some of the other means of securing web services? I think now that I have a "stake in the ground" with this architecture, it will enable me to start grasping some of the other concepts and be able to compare them when I have to make my own choices.
And if anyone from Vertigo reads this, I happened to have a chance to talk with Keith Ballinger a bit about what WSE might be able to buy for this authentication ticket scheme (I was looking for LESS CODING) He thinks (based on my description of the scheme to him) that it would be gobs of code with WSE also. Do you agree? It's too important to be without this security, but is there truly just no pretty way to get it in?
This is actually why I have come down this path. I love the scheme but it's such a great proliferation of code throughout all of the layers and so many methods in my application, I have been trying to figure out how to do it differently. My perception may be due to the fact that I was adding it to a pre-existing app, rather than starting from scratch. This app that I have is an architecture that I already have opportunity to reuse and I'm worried about the weight of all of this code I would be like to investigate a more efficient means of achieving the same ends.
Thanks very much. I am really looking forward to this conversation.
Julie
I'm actually switching an app of mine from WS-Security (using WSE) to the AuthenticationTicket Method. I ran into too many troubles and am getting the feeling it's a bit too early to use WS-Security. Not a whole lot on it yet out there.
What's not straight forward about the AuthenticationTicket? Is there anything I can help explain?
Geeze that was fast Eric. I guess that's the moderator advantage.
I am in NO WAY saying that there is something that is not straight forward about the Authentication Ticket. I understand it. I love what it does. It is a very cool solution.
I am curious about how it compares to some of the other methods, what the pluses and minuses are. That is other methods within WS-Security - not even with WSE.
oops - Erik! Sorry, I'll remember next time "K" not "C"
Don't worry about it, at least you noticed that you misspelled my name...most people never noticed :p
Well, I've only used WS-Security with WSE and honestly, it was a pain. It was generally straight forward to add in the Secruity Token with the Username and Password, but then to actually check for it on the server was not straight foward at all! I was a little confused with the IPasswordProvider at first too.
If you want to check out the article that I used to figure it out, go here: <a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwssecur/html/wssecauthwse.asp">WS-Security Authentication and Digital Signatures with Web Services Enhancements</a>
Personally, I like the AuthenticationTicket code better than what was all involved in that article :p
I saw from a previous thread your link to that article <g> and kept getting pointed back to it from MSDN also.
Having seen the other side, what do you think about the concept of using the authentication ticket to "remember" that a user was authenticated for a little while at least vs. just sending the authentication information every single darned time and authenticating on the database every single darned time.
Do you think that that is the reason they used it? To try to let the webserver remember for at least a little while, but not so long that someone could take advantage of it?
I probably won't stick around tonight to see your response! Even the dog is saying "bed time!"
julie
Well, coming from an ASP.NET background, my first thought is yes, it would be better, but the problem with WebServices is that they're stateless, so you really have to send the token every time.
Now, the reason (I believe) that this isn't really a big deal is because as we move away from web applications and more into smart clients, we can actually spare the extra processing time and bandwidth that these sorts of things take, because now, the web server doesn't really have to do much at all! Basically, the WebService in the TaskVision example is just acting as a Data Layer and I'd say any web server should be able to handle that just fine, since it might be used to ASP.NET where it's doing a whole lot more than just being a Data Layer, it's also generating the UI and sending all that UI data over the wire. Again, in something like TaskVision, the data processing is done on the server, while the rest is all done on the client, leaving the server free to do other things, like process AuthenticationTickets every hit, etc. I think TaskVision at least caches the ticket after the first time it's created, right?
Anyway, if there's anything else I can do for you, just le me know :)
I'm not sure if I'm asking my question correctly.
I think what I'm trying to get at is why are we CACHEING the authentication tickets?
I see two ways to do this (I know for sure that there are probably more but this is why I need to learn!!)
1 - Send the authentication information FROM the Client to the webservice every single time. Authenticate against the database every single time. This is the usernametoken method. I know you had a hard time catching it in WSE, but isn't there a mechanism for this without WSE?
or
2 (TaskVision) - Send the authentication information. Get a ticket. Cache the ticket in the webserver. Return the ticket to the client. Next time client wants data, client sends ticket. Ticket is confirmed to be good on webserver (within 2 minutes from creation). Authentication against the database is not necessary. Client again wants data and sends ticket with request. This time the ticket has timed out, so the login and password are sent a 2nd time to the db for authentication. On confirmation, webserver creates a 2nd ticket, caches that and returns it to the client.
So I'm trying to understand the reasoning of using one over the other and my thought is that it is to try to save some of the trips to the database.
Does that make sense?
The statelessness is not an issue in either case.
I see that some of the specifications for ws-security's future are aimed at "conversation". That is what we are trying to do here. Have a conversation with the webservice without having to constantly reauthenticate but at the same time without having to constantly worry about replay attacks, etc.
julie
well, the caching as far as I understand it currently is so that once it's gone back to the DB to verify the data, it doesn't have to actually create the AuthenticationTicket again. Just a little time saver for the server.
as for why this ticket isn't stored on the client for calls after that, I'd say is for security reasons. If the ticket is stored on the client, that's just one less secure place for a hacker to try to get at it. remember, this is a best practices sample application and right now, microsoft is hugely pushing security, so that's why i would imagine that the process is done this way in TaskVision.
i don't know if it's the best way, but my personal approach to security is that if you're not a target, don't worry about it. now, that said, everyone is a target for certain security risks, but MOST people are not targets for MOST security breach possibilities.
TaskVision is up with all the source code so if you feel comfortable (as I would for the things I do) with changing it so it stores the ticket on the client and save the lookup work to the DB on the WebService, then feel free. Maybe you could post the code changes up to for those others that are interested in that type of scenario.
Good luck and let me know if there's anything else I can "try" to explain.
Also, any MS guys care to confirm or shoot me down on my guess on why you guys did things that way?
Erik, I'm flattered that you think that I could possibly come up with a better way than the Vertigo team <g> but really, I highly doubt it. (I'm kidding, of course.)
I hope that I haven't given the impression that I am challenging this method because I'm really not at all. Truly, I was just looking for a comparison of the different methods and wanted to use this one as a starting point because it is the only one so far that I have ever implemented.
I think that you and I are actually in agreement - that the cache is to save some time (and resources) for the webserver in reauthenticating against the db. I'm not sure what you mean by storing the ticket on the client. The ticket is returned to the client upon creation but not persisted or anything. It is just used to pass back to the webservice as proof. When the webserver times it out, then a new one is created and returned to the client. But each ticket is only valid for the timeout period and therefore, there would be no use in storing it. But maybe I completely misunderstood what your saying. Regardless, I think that really you and I are "on the same page" so to speak.
There is so much to learn, and security, as you say, is coming front and center. So I am trying to get it all sorted out in my poor little brain. One thing I can tell from all of my reading is that the Authenticated Tickets are a heck of a lot easier than Kerberos tickets!!
On another note, I don't think that my client's data is a target and none of us care too much if anyone looks at the data. But some of the web methods in this solution and future ones that I will be doing WRITE to the database and I just wouldn't want to take the chance of some bored (but way smarter than me) person taking advantage of loose ends. Also, this is a perfect project for me to use for learning the harder stuff and then I will be prepared when it is really important to use it.
Hey let's rename this the Julie & Erik thread. Maybe we should just i.m.! <g> I know that the forums are generally used for question/answer. But I really like the ability to hash out ideas also, not just solve specific problems.
So, I hope I'm not being a huge PIA. It's just that I really want to LEARN from this sample, not just copy it.
julie
<quote>
It's just that I really want to LEARN from this sample, not just copy it.
</quote>
Now I know we're DEFINITELY on the same page ;)
Don't worry about, you're fine, I like discussing concepts too. Feel free to send me an e-mail sometime, Julie, and we can exchange IM addresses ;)
