Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p><strong>Authentication</strong></p> <p>WCF Data Services allow for a variety of authentication options, as described on MSDN : Securing WCF Data Services. From the available methods, Windows authentication is the most secure, using either the <strong>NTLM</strong> or <strong>Kerberos</strong> mechanism. Due to the constraints on cross-platform availability, the most appropriate and secure authentication method that can be used is NTLM, as it is available on almost all current platforms: Android (from version 4.0 "<em>Ice Cream Sandwich</em>"), iOS, Linux, UNIX, Windows.</p> <p>Setting up Windows authentication for an OData service hosted on IIS means disabling Anonymous Access and enabling Integrated Windows authentication. A more detailed guide can be found at <a href="http://blogs.msdn.com/b/astoriateam/archive/2010/05/10/odata-and-authentication-part-2-windows-authentication.aspx" rel="nofollow">Odata and Windows Authentication</a>.</p> <p>For a more fine-grained control of the users allowed to access the service, access can be granted or denied to both user roles/groups, as well as specific users, directly from the configuration file (i.e. web.config). The syntax for allowing access for a specific user is described below. For maximum security, it is advised to deny access to all users/groups, and then explicitly allow access, as required. The rules in between the authorization tags are taken in order (i.e. allowing user DOMAIN\user access takes precedence over the denial for all users)</p> <pre><code> &lt;authorization&gt; &lt;allow users="DOMAIN\user"/&gt; &lt;-- Deny access to every other authenticated or anonymous user &lt;deny users="*" /&gt; &lt;deny users="?" /&gt; &lt;/authorization&gt; </code></pre> <p>If the authorization tag is not explicitly defined in the configuration file, then IIS will authenticate and allow access for all connecting users that are recognized (in the Active Directory or local machine).</p> <p>Setting up Windows authentication in a cross-domain environment is possible, but requires either:</p> <ul> <li>a trust to be established between the domains (so that IIS can authenticate external users), or </li> <li>the same username/password combination to be present on both domains or</li> <li>the client in the external domain authenticates with credentials valid for the server domain.</li> </ul> <p>The available options for such situations are described in more detail in <a href="http://www.olegsych.com/2009/05/crossing-domain-boundaries-windows-authentication/" rel="nofollow">this</a> blog post.</p> <p><strong>Impersonation</strong></p> <p>In order to be able to log in to the database, and retrieve the desired data using the Windows Account credentials sent to the WCF Data Service, the service needs to impersonate the user. This can be done in either in code, or in configuration</p> <ul> <li>In the configuration file (i.e. web.config), the following settings<br> must be made: </li> </ul> <blockquote> <pre><code> identity impersonate="true" </code></pre> </blockquote> <ul> <li><p>If it is not desired for the entire service to run under the credentials of the connecting user, impersonation can be set up programmatically, where needed, in the following way:</p> <blockquote> <p>lUser = TryCast(HttpContext.Current.User.Identity, WindowsIdentity)</p> <p>lUserContext = WindowsIdentity.Impersonate(lUser.Token)</p> </blockquote></li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload