NGWS SDK Documentation  

This is preliminary documentation and subject to change.
To comment on this topic, please send us email at ngwssdk@microsoft.com. Thanks!

Remoting Security Concepts

Related Topics

ASP+ Security

Role based Security

HTTP Channel WebSecurity

WebSecurity is based on the Internet standards for secure communication and authentication. The HTTP Channel utilizes System.Net on the sender and IIS with ASP+ for security on the receiver to provide Web Security. The credentials (Username, Password and optionally Domain) can be set on the HTTP Channel Message Sink Properties. The Remoting infrastructure passes the credentials to System.Net, which sends them to the server. HTTP The Channel Message Sink properties contain a PreAuthenticate property that by default are will send the credentials on the first message.

Authentication

Applications hosted in ASP+ can be configured for authentication using the combination of IIS and ASP+ security. The ASP+ Application vroot e.g. http://contoso.com/Cart is configured for security in IIS and ASP+. See the IIS documentation and ASP+ Security topics for details on configuring IIS and ASP+ for authentication.

Anonymous

Allows users to establish an anonymous connection, select this option. Your server logs on the user with an anonymous or guest account.

Note: You must turn off Anonymous if you want to use basic, digest or integrated windows authentication.

Basic Authentication

Basic authentication is a security mechanism using a standard HTTP mechanism in which user information is sent and received as clear text. It uses a base64 encoded string that contains the user name and password. (The term clear text indicates data is transmitted as clearly readable text characters rather than binary bit-streamed information, which is not text-formatted.) Passwords and user names are encoded but not encrypted in this type of authentication. It is important to note that Basic authentication results in the transmission of passwords across the network in an unencrypted form. A determined computer vandal equipped with a network monitoring tool could intercept user names and passwords.

Basic Authentication can be useful when the Application just needs some identifier for the calling Application.

Digest Authentication

Digest authentication sends a hash value over the network rather than the password. This method works across proxy servers and other firewalls.

A challenge-response scheme that challenges using a nonce (a server-specified data string) value. A valid response contains a checksum of the user name, the password, the given nonce value, the HTTP method, and the requested URI.

Digest authentication addresses many of the weaknesses of Basic authentication. Most notably, the password is not in clear text when you use Digest authentication. In addition, Digest authentication can work through proxy servers, unlike integrated Windows authentication.

Digest authentication is useful when the Application needs a stronger level of authentication than basic.

Cookie Authentication.

Cookie authentication is generally used to refer to a system whereby unauthenticated requests are redirected to an HTML form (using HTTP client-side redirection). The user provides credentials and submits the forms. If the application authenticates the request, the system issues a cookie that contains the credentials in some form or a key for reacquiring the identity. Subsequent requests are issued with the cookie in the request headers and they are authenticated and authorized by an ASP+ handler using whatever validation method the application desires.

It should be noted that cookie authentication is often used for personalization, where content is customized for a known user. In some of these cases, identification is the issue rather than authentication, so it’s enough merely to store the user name (in a durable cookie) and use that to access the user personalization information. For more information on ASP+ personalization services, please refer to the User Profiles specification.

Integrated Windows Authentication

Integrated Windows authentication uses a cryptographic exchange with the user’s Internet Explorer Web.

Integrated Windows authentication—formerly known as both NT LAN Manager (or NTLM) and Windows NT Challenge/Response authentication—is more secure than Basic authentication. This authentication scheme works especially well in an intranet environment where users have Windows domain accounts.

In integrated Windows authentication, the browser attempts to use the current user’s credentials from a domain logon. If those credentials are rejected, integrated Windows authentication will prompt the user for a user name and password by means of a dialog box. When integrated Windows authentication is used, the user’s password is not passed from the client to the server. If a user has logged on as a domain user on a local computer, the user won’t have to be authenticated again when accessing a network computer in that domain.

The user is not prompted for a user name and password for each HTTP request; rather, this will happen only when the cached credentials do not have sufficient permissions to access a specific page or file.

Role-based Security in Managed Applications

Role-based Security is a common application concept in which one makes Authorization decisions based on the identity and/or role(s) for the entity on whose behalf an application is executing. The definition of “roles” is typically application specific as are the conditions under which one is willing to authorize specific actions.

It is common for applications developers to make authorization decisions based on the identity and/or role(s) associated with the execution context. One often sees this in financial or business systems as a means of policy enforcement. For example, one may impose limits on the value of a transaction depending on the role of the user making the request. Clerks may be able to process transactions up to some set value, supervisors to some higher limit, and VPs yet a higher limit. Another example is business systems requiring multiple approvals to complete an action. Consider a purchasing system in which any employee may generate a purchase request, but only a purchasing agent may process that request into a Purchase Order that can be sent to the supplier.

In the past, such requirements were often handled using proprietary mechanisms. Microsoft first introduced infrastructure to support this type of “role-based” security with MTS and recently COM+1.0 services. The NGWS runtime provides similar support but does so in a way that is well integrated into the NGWS programming model and scales to the needs of distributed internet applications.

Integration with the NGWS programming model means that role-based security mechanisms:

Impersonation

ASP+ Security

Windows Identity Impersonation

WindowsIdentity.Impersonate

ImpersonationContext.Undo

Secure Communication in ASP+

The HTTP Channel hosted in IIS with ASP+ supports sending and receiving secure communication using SSL (Secure Sockets Layer). See the IIS documentation for configuring SSL. Start the URLs with https in calls to Activator.GetObject, Activator.CreateInstance, items in the Remoting Configuration file or wherever URLs are used to specify a remote object, remote WebService or Remoting application.

ASP+ HttpRequest.IsSecureConnection in the HttpContext returns a boolean that indicates whether the Http connection is secure i.e. HTTPS.