{"id":1293,"date":"2010-05-10T13:26:56","date_gmt":"2010-05-10T13:26:56","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/odatateam\/2010\/05\/10\/odata-and-authentication-part-2-windows-authentication\/"},"modified":"2018-09-04T18:01:01","modified_gmt":"2018-09-04T18:01:01","slug":"odata-and-authentication-part-2-windows-authentication","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/odata\/odata-and-authentication-part-2-windows-authentication\/","title":{"rendered":"OData and Authentication \u2013 Part 2 \u2013 Windows Authentication"},"content":{"rendered":"<p>Imagine you have an OData Service installed on your domain somewhere, probably using the .NET Data Services producer libraries, and you want to authenticate clients against your corporate active directory.<\/p>\n<p>How do you do this?<\/p>\n<h3>On the Serverside<\/h3>\n<p>First on the IIS box hosting your Data Service you need to turn on integrated security, and you may want to turn off anonymous access too.<\/p>\n<p><a href=\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/23\/2019\/02\/TurnOnIntegratedSecurity.png\"><img decoding=\"async\" style=\"border-right-width: 0px;border-top-width: 0px;border-bottom-width: 0px;border-left-width: 0px\" title=\"TurnOnIntegratedSecurity\" border=\"0\" alt=\"TurnOnIntegratedSecurity\" src=\"https:\/\/devblogs.microsoft.com\/odatateam\/wp-content\/uploads\/sites\/23\/2010\/05\/TurnOnIntegratedSecurity_thumb.png\" width=\"244\" height=\"102\" \/><\/a> <\/p>\n<p>Now all unauthenticated requests to the website hosting your data service will be issued a HTTP 401 Challenge. <\/p>\n<p>For Windows Authentication the 401 response will include these headers:    <br \/><font face=\"Courier New\">WWW-Authenticate: NTLM      <br \/>WWW-Authenticate: Negotiate<\/font><\/p>\n<p>The NTLM header means you need to use Windows Authentication.    <\/p>\n<p>The Negotiate header means that the client can try to negotiate the use of <a href=\"https:\/\/msdn.microsoft.com\/en-us\/library\/aa378747(v=VS.85).aspx\">Kerberos<\/a> to authenticate. But that is only possible if both the client and server have access to a shared <a href=\"http:\/\/msdn.microsoft.com\/en-us\/library\/aa378164(v=VS.85).aspx\">Kerberos Key Distribution Centre<\/a> (KDC).<\/p>\n<p>If, for whatever reason, a KDC isn\u2019t available a <a href=\"http:\/\/www.innovation.ch\/personal\/ronald\/ntlm.html\">standard NTML handshake<\/a> will occur.<\/p>\n<h4><font color=\"#404040\">Detour: Basic Authentication<\/font><\/h4>\n<p><font color=\"#404040\">While we are looking into Windows Authentication it is worth quickly covering basic auth too because the process is very similar.<\/font><\/p>\n<p><font color=\"#404040\">When you configure IIS to use Basic Auth the 401 will have a different header:      <br \/><font face=\"Courier New\">WWW-Authenticate: Basic realm=&quot;mydomain.com&quot;<\/font><\/font><\/p>\n<p><font color=\"#404040\">This tells the client to do a <\/font><a href=\"http:\/\/en.wikipedia.org\/wiki\/Basic_access_authentication\"><font color=\"#404040\">Basic Auth handshake<\/font><\/a><font color=\"#404040\"> to provide credentials for &#8216;mydomain.com&#8217;. The \u2018handshake\u2019 in Basic Auth is very simple \u2013 and very insecure \u2013 unless you are also using https.<\/font><\/p>\n<h3>On the Clientside<\/h3>\n<p>Now that a NTLM challenge has been made, what happens next?<\/p>\n<h4>In the browser:<\/h4>\n<p>Most browsers will present a logon dialog when they receive a 401 challenge. So assuming the user provides valid credentials they are typically free to start browsing the rest of site and by extension the OData service.<\/p>\n<p>Occasionally the browser and the website can &quot;Negotiate&quot; and agree to use kerberos, in which case the authentication can happen automatically without any user input.<\/p>\n<p>The key takeaway though is that in a browser it is pretty easy to authenticate against a Data Service that is secured by Windows Authentication.<\/p>\n<h4>.NET Client Application:<\/h4>\n<p>In a .NET client application using the standard .NET Data Services client \u2013 or for that matter the <a href=\"https:\/\/odata.codeplex.com\/\">open source version<\/a> \u2013 you need to tell data services your credentials.<\/p>\n<p>Which you do like this:<\/p>\n<p><font face=\"Courier New\">MyDataContext ctx = new MyDataContext(uri);      <br \/>ctx.Credentials = System.Net.CredentialCache.DefaultCredentials;&#160; <br \/><\/font>    <br \/>The example above makes sense if your client application is running under a windows account that has access to the server. If not however you will have to create a new set of NetworkCredentials and use them instead.<\/p>\n<p><font face=\"Courier New\">ctx.Credentials = new NetworkCredential(      <br \/>&#160;&#160;&#160; &quot;username&quot;,       <br \/>&#160;&#160;&#160; &quot;password&quot;,       <br \/>&#160;&#160;&#160; &quot;domain&quot;);<\/font><\/p>\n<p>As you can see, pretty simple.<\/p>\n<h4>Silverlight Client Application:<\/h4>\n<p>Silverlight on the other hand is a little different. <\/p>\n<p>If it is running in the browser \u2013 the only option in SL2 &amp; 3 &#8211; then by default the Data Services client will re-use the cookies and authentication headers already established by the browser. <\/p>\n<h5>Silverlight 2 &amp; 3:<\/h5>\n<p>In fact in Silverlight 2 &amp; 3 that is all it can do. The Silverlight client library doesn\u2019t have a Credentials property so there is no way to use different credentials.<\/p>\n<p>Typically if your SL app is hosted by a site that requires Windows Authentication, you don\u2019t have a problem \u2013 because in order to download the Silverlight app, you need to authenticate in the browser first.<\/p>\n<p>Which means from the perspective of the Data Service you are already authenticated.<\/p>\n<p><strong><u>Warning:<\/u><\/strong> While it is possible in Silverlight to do x-domain calls, so long as the other domain has a correctly configured <a href=\"http:\/\/msdn.microsoft.com\/en-us\/library\/cc197955%28VS.95%29.aspx\">ClientAccessPolicy.xml<\/a> file, if the other domain needs you to logon, there is no way to provide your credentials.<\/p>\n<h5>Silverlight 4:<\/h5>\n<p>Silverlight 4 is significantly more flexible, because it adds a Credentials property to the DataServiceContext. Which you can use to provide a different set of credentials if required.<\/p>\n<p>In fact, if you think about it, because SL4 can run &#8216;out of browser&#8217; the ability to set credentials directly is absolutely vital.<\/p>\n<p>Despite this new feature in SL4 there are still some differences between .NET and SL4. <\/p>\n<p>In SL4 there is no CredentialsCache so you can\u2019t re-use the DefaultCredentials from the client. However we added a very handy property instead:<\/p>\n<p><font face=\"Courier New\">ctx.UseDefaultCredentials = true;<\/font><\/p>\n<h4>Summary:<\/h4>\n<p>As you can see using Windows Authentication with OData is pretty simple, especially if you are using the Data Services libraries. <\/p>\n<p>But even if you can\u2019t, the principles are easy enough, so clients designed for other platforms should be able to authenticate without too much trouble too.<\/p>\n<p>Next time out we\u2019ll cover a more complicated scenario involving OAuth.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Imagine you have an OData Service installed on your domain somewhere, probably using the .NET Data Services producer libraries, and you want to authenticate clients against your corporate active directory. How do you do this? On the Serverside First on the IIS box hosting your Data Service you need to turn on integrated security, and [&hellip;]<\/p>\n","protected":false},"author":512,"featured_media":3253,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[15,48,67],"class_list":["post-1293","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-odata","tag-authentication","tag-odata","tag-silverlight"],"acf":[],"blog_post_summary":"<p>Imagine you have an OData Service installed on your domain somewhere, probably using the .NET Data Services producer libraries, and you want to authenticate clients against your corporate active directory. How do you do this? On the Serverside First on the IIS box hosting your Data Service you need to turn on integrated security, and [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/odata\/wp-json\/wp\/v2\/posts\/1293","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/odata\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/odata\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/odata\/wp-json\/wp\/v2\/users\/512"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/odata\/wp-json\/wp\/v2\/comments?post=1293"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/odata\/wp-json\/wp\/v2\/posts\/1293\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/odata\/wp-json\/wp\/v2\/media\/3253"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/odata\/wp-json\/wp\/v2\/media?parent=1293"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/odata\/wp-json\/wp\/v2\/categories?post=1293"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/odata\/wp-json\/wp\/v2\/tags?post=1293"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}