views:

118

answers:

2

I’ve inherited a rather convoluted project. The original designer created a “cookie” that appears to be server side rather than client based (though I could be very wrong on that part). He is using it for what he called “Least Privileges, Single Sign On”. I have the following code in all of the Web Service Proxies he set up:

[WebServiceBinding(Name = "ISecurityManager", Namespace = "urn:riv:apis:security:forms:ver1")]
public partial class SecurityManager : SoapHttpClientProtocol, ISecurityManager
{
    public SecurityManager()
    {
        //Url = CookieManager.WebServiceUrl(String.Empty, ref CookieContainer);
        // I’d like to replace the following code with a call like this...

        CookieContainer = new System.Net.CookieContainer();
        string urlSetting = ConfigurationManager.AppSettings["SecurityManager"];

        if (urlSetting != null)
            Url = urlSetting;
        else
            Trace.TraceWarning("No URL was found in application configuration file");

        string cookieName = FormsAuthentication.FormsCookieName;
        string cookiePath = FormsAuthentication.FormsCookiePath;
        string cookieDomain = Properties.Settings.Default.CookieDomain;
        HttpCookie authCookie = HttpContext.Current.Request.Cookies[cookieName];

        if (null != authCookie)
            CookieContainer.Add(new Uri(urlSetting), new System.Net.Cookie(cookieName, authCookie.Value, cookiePath, cookieDomain));
    }
….

I also have this code pretty much everywhere:

string cookieName = FormsAuthentication.FormsCookieName;
string SecurityContext.ApplicationName = HttpContext.Current.Request.Cookies[cookieName].Path;
string SecurityContext.UserName = HttpContext.Current.User.Identity.Name;

if (!string.IsNullOrEmpty(SecurityContext.UserName))
….

In all instances, when it goes to get the authCookie, it comes up null or the SecurityContext.UserName is blank. I’m not a cookie guru and a lot of this guy’s code is obfuscated – and zero documentation.

Can anyone make heads or tails out of the intent of the code blocks?

TIA

A: 

Well obviously he's attempting to create a security/authorization provider that apparently doesn't work well or at all. I recommend you look at Enterprise Library for this functionality. Security Application Block QuickStart. Then look at caching the security token.

Chris Marisic
+1  A: 

FormsAuthentication for a web service method? Storing authentication credentials in a cookie? There are so many things wrong with this story. (Note: heavy obfuscation of code should be taken as a sign.)

The intent of the code blocks, as it appears, is using the cookie framework for user identification during a method call. It assumes the user has already been authenticated and that the authentication cookie is present in all requests.


EDIT: a bit more information on "server-side cookies" -- the references you see to System.Net.Cookie and such are .Net Framework classes for handling cookies. Cookies are client-side pieces of data that reside either in-memory for the client (usually a web browser), and/or saved as text files somewhere on the local file system of the client. Most web applications that set client-side cookies assume they are dealing with a web browser, as all the major browser providers support cookies.

When a web browser is used to make a request to a URL, lots of information is sent in the background that is hidden from the user: IP address, the type of browser and OS, etc. Included in this list are cookies for that given URL domain (there are HTTP rules that browsers agree to). The code you're looking at are specific .Net Framework classes for dealing with those cookie values in a structured way.


Most applications that consume web services are completely stateless -- no cookies, no sessions, nothing. While it's possible that a client to a web service may implement cookie support, assuming or requiring cookie support for a web service is folly.

In the code scenario you've debugged to detect null values, most likely the calling application does not support cookies, effectively rendering the entire code block invalid. This is broken-by-design.

I cannot find a sensible way of improving this code block that doesn't involve a teardown of the entire structure. Given your suggested level of familiarity, spend a little time on web security 101. Get familiar with the concepts of authentication, sessions, (and cookies, too.) You'll know you're ready to proceed as soon as you realize that security is something you don't invent yourself.

jro