Microsoft® .NET Services Overview
Introduction
Microsoft .NET Services is a set of Microsoft-built and hosted
cloud infrastructure services for building Internet-enabled applications. .NET Services constitutes an Internet
Service Bus that provides applications with a common infrastructure to name,
discover, expose, secure, and orchestrate Web services.
More specifically, .NET Services addresses several broad
areas of functionality that are common prerequisites for many Internet-enabled
applications. Internet-based and -scaled infrastructure comes with significant
development and maintenance cost, and a single-purpose infrastructure is even
more expensive to operate in a secure, reliable, and highly available manner. .NET
Services is designed to significantly lower the entry barriers for new types of
interconnected Internet-scale applications regardless of whether they are
Web-based, they work through application-to-application federation, or they
want to exploit the rich user experience and media capabilities of modern
desktop environments. The following are the three broad areas:
-
Service Bus: The Service Bus
provides a hosted, secure, and broadly accessible
infrastructure for pervasive communication, large-scale event distribution,
naming, and service publishing. Services can be exposed through the Service
Bus Relay, providing connectivity options for service endpoints that
would otherwise be difficult or impossible to reach. Endpoints can be located behind
network address translation (NAT) boundaries, or bound to frequently
changing, dynamically assigned IP addresses, or both.
-
Access Control Service: The Access
Control
Service is a hosted, secure, standards-based infrastructure for multiparty,
federated authentication and rules-driven, claims-based authorization. The
Access Control Service's capabilities range from simple, one-step,
user name/password-based authentication and authorization with Web-style HTTP
requests to sophisticated WS-Federation scenarios that employ two or more
collaborating WS-Trust Security Token Services. The Access Control Service allows
applications to rely on .NET Services solution credentials for simple
scenarios or on on-premise enterprise accounts managed in Active Directory
and federated with the Access Control Service via next-generation Active Directory
Federation Services.
-
Workflow Service: The Workflow Service
provide a hosted environment for service orchestration based on the familiar
Windows Workflow Foundation development experience. The Workflow services
will provide a set of specialized activities for rules-based control flow,
service invocation, as well as message processing and correlation that can
be executed on demand, on schedule, and at scale inside the .NET Services
environment.
Architectural Overview: Service Bus
The Service Bus provides a
broad range of cloud-based and cloud-assisted connectivity features. The
following are the key
capabilities of the Service Bus:
- A federated namespace model that provides a
shared, hierarchical namespace into which services can be mapped. This
allows providing any endpoint with a stable, Internet-accessible URI,
regardless of location.
- A service registry service that provides an opt-in model
for publishing service endpoints into a lightweight, hierarchical, RSS-based
discovery mechanism.
- A lightweight and scalable publish/subscribe event
bus.
- A relay and connectivity service with advanced NAT traversal and
pull-mode message delivery capabilities acting as a "perimeter network
(also known as DMZ, demilitarized zone, and screened subnet)
in the sky" for services that would otherwise be unreachable due to
NAT/Firewall restrictions or frequently changing dynamic IP addresses, or
that do
not allow any incoming connections due to other technical limitations.
Namespace
When using the Service Bus (see below),
services register themselves in a global namespace structure. Each .NET Services
solution is assigned a private branch of the namespace hierarchy into
which the account holder can map their services in any hierarchical organization
structure they deem suitable for their needs. Even though the namespace feature
is coupled to the use of the Service Bus, it is worth considering this
capability as a separate feature.
Expressed as a URI prefix, the root of any account's private
namespace hierarchy is anchored at sb://servicebus.windows.net/services/solutionname/.
Beneath this root, the account holder can map services into a tree-like naming
structure. Possible strategies are to subdivide their branch of the global
namespace by application-name, service-name, and endpoint-name, or by
application-name, service-name, endpoint-group-name, and endpoint-name.
A CRM application that provides access to customer
information can organize its namespace by statically mapping services into an sb://servicebus.windows.net/services/accountname/CRM/ with
a ./CRM/CustomerInfo service and a ./CRM/CustomerInfo/IWSContactDataAccessV1
service endpoint. Other applications,
services, and endpoints can reside parallel to these names.
An application with a more dynamic, environment-dependent
structure, such as a media-sharing application that provides access to electronic
program guide data for TV, might subdivide the namespace into a ./TV
branch, with ./TV/Channels providing a scope for the channel lineup and
virtual, environment-dependent endpoints with their respective names mapped
underneath, for example,
./TV/Channels/MSNBC/ and ./TV/Channels/MSNBC/Schedule.
Applications that generate short-lived endpoints for
peer-to-peer callbacks or notifications, such as a peer-to-peer Chat
application, would likely register temporary, unique names like
./Chat/Whispers/<guid> in which the rightmost
segment identifies a volatile endpoint whose name is a runtime-generated GUID.
Any path through the naming tree can be expressed
as a fully qualified URI. If the owner of the .NET Services solution
jeffsmith were hosting the imaginary media service mentioned above, the
HTTP-GET URI for obtaining today's MSNBC schedule might be: sb://servicebus.windows.net/services/jeffsmith/TV/Channels/MSNBC/Schedule.
Particularly noteworthy about the naming
capabilities of the Service Bus is that they provide a federated and
effectively unconstrained naming mechanism that is not location-scoped. Here,
services are mapped into a common namespace, but their actual network location
is intentionally decoupled from the host portion of the URI, which provides
location agility. Contrary to the common use of URIs, where there is a single (or a
narrowly scope set of) network listener(s) for each URI that is immediately identified by protocol
scheme, host, and port, the Service Bus naming scheme allows for independently listening, freely
relocatable endpoints identified by the leaves
of the naming tree.
This is significantly different from widely used naming
services like dynamic DNS, where the structure is also hierarchical, but where
names are still tightly related to publicly reachable network addresses or at
least individual ports on such addresses. The combination of the federated
namespace and the Service Bus relay provides a naming mechanism that is
more dynamic, has lower update latency, and is entirely decoupled from the service's
actual location or transport protocol (or both).
Service Registry
The service registry service provides an opt-in model for
publishing service endpoints into a lightweight, hierarchical, RSS-based
discovery mechanism. The service registry is layered over the naming structure
and allows publishing services into a nested structure of RSS feeds simply by
flipping a switch on an endpoint's configuration. The RSS feeds along the naming
hierarchy are a simple way to represent and discover services.
Relay
The relay capability of the Service Bus enables you
to easily expose secure, Internet-accessible service endpoints with well-known
addresses regardless of the network location of the machine that is hosting the
service. This enables hosting services on, and exposing service endpoints from,
machines with constrained Internet connectivity where:
- The host machine resides behind a Network Address Translation (NAT)
service in which its primary IP (v4) address is in a private range that is not
Internet-addressable (i.e. 10.x.x.x, 192.168.x.x,
172.16.x.x-172.31.x.x).
- The host machine resides behind one or multiple firewalls that prevent
incoming connections.
- The host machine or its Internet gateway does not have a static
(permanently assigned) IP address with a publicly registered domain name.
All of these constraints apply to the vast majority of machines in corporate,
small business, and home networking environments. For many software vendors,
these constraints represent a major obstacle for writing more powerful,
network-aware applications that leverage Internet connectivity for the benefit
of their customers, for example, for proving direct business-to-business connectivity
that even small businesses can participate in.
To provide the desired connectivity, the Service Bus acts as a Web
Service intermediary router. In most respects, the Service Bus is completely
transparent for SOAP messages and protocols used between endpoints. Endpoints
that connect through the Service Bus can use message-level security (with or without reliance on the
Access Control Service) to
protect messages and therefore make it effectively impossible for the Service
Bus to inspect or modify elements in the message if that were a concern. Endpoints can also use
other WS-* protocols, such as WS-ReliableMessaging or WS-Coordination/WS-AtomicTransaction,
or any other custom Web Services protocol transparently through the Relay.
Additionally, the Service Bus can also act as an intermediary for
HTTP messages. While this functionality might seem similar to the function of a
RFC 2616 HTTP
proxy, the relay's role towards client and service is in fact substantially
different. The Service Bus is acting as an externally hosted HTTP listener to allow the service receiving and responding to HTTP requests
regardless of its network location. In contrast, a HTTP proxy expects that the
accessed HTTP service is actively listening for messages on a well-known address
and port specified by the client.
The SOAP and HTTP relay capabilities are implemented on top
of a set of messaging protocol primitives whose functionality is fully exposed
through the .NET programming model today. Those underlying messaging protocol
primitives will, over the course of the next releases, be gradually exposed for
consumption and composition from other runtime environments or for the
construction of alternate .NET programming models that customers might want to
provide over these primitives.
The .NET programming model for the Service Bus provides the following
bindings. All bindings create publicly reachable and, if desired, publicly
discoverable HTTP listener endpoints on the Service Bus:
-
BasicHttpRelayBinding: Uses
HTTP as the relay transport.
-
NetTcpRelayBinding: Uses TCP as the relay
transport.
-
NetOnewayRelayBinding: Supports only one-way messages.
-
NetEventRelayBinding: Supports one-way
multicast eventing and allows N event publishers and M
event consumers to rendezvous at the same endpoint.
- WebHttpRelayBinding: Supports plain HTTP messages with support for XML and Raw (binary) message
encodings.
- WS2007HttpRelayBinding: Supports SOAP 1.2 messaging with the latest OASIS standards for Reliable
Message Exchange and Security.
- WSHttpRelayBinding: Supports SOAP 1.2 messaging with the draft WS-* standards for Reliable
Message Exchange and Security that are available in Windows Communication
Foundation (WCF) 3.0.
Architectural Overview: Access Control Service
The Access Control Service is an easily
configurable, cloud-based WS-Trust Security Token
Service (STS) that supports the authentication of User name/Password, Windows CardSpace, Certificate, and 3rd-party
STS-issued SAML Token credentials and provides an authorization framework
that uses flexible, claims-based rules.
Federated Security Primer
A Security Token Service (STS) issues tokens asserting
claims to a requestor desiring access to resources on
direction of and for consumption by a relying party that
provides access to these resources.
In the Web services realm, token is
commonly used as a generic term for a container that holds security information. A token is typically issued for a particular purpose and for
a particular receiver. For all other parties involved in a federated security
scenario, the tokens are fully or partially opaque entities. Tokens are issued
in a way that it is possible to detect whether their contents have been tampered with
(they are signed), and the issuer of the token can encrypt them so that only a
particular party can access the token contents.
A claim is a statement that a participant in a security
relationship makes about itself. A user might claim that he/she possesses
certain properties, such as being a member of a particular group, being of a
certain age, or having a particular e-mail address. With an identity claim, the
user claims that he/she is indeed who the other participants believe the user
is.
By themselves, claims are unverified statements. To be
trustworthy, a claim needs to be verified and
corroborated by an authority that all participants in the security
relationships trust, which is a role commonly taken on by an
STS. Corroborated
claims are transferred between the participants in the security
relationship inside of tokens.
For claims to be easily (and programmatically)
understood by a multitude of collaborating parties, claims are of a particular
form. A claim commonly consists of a triplet of information: dialect, type,
and right. The dialect is effectively a namespace that provides a scope for a
particular set of claim types. An example for such a dialect is the
Microsoft
Information Card Profile V1.0, which defines a
number of claim types related to people's personal information. The right
associated with the claim distinguishes whether the claim is an identity claim
("This is me.") or whether the claim is about possessing some particular property
("My e-mail is this.").
A credential is an information set that
contains a claim about the identity of a service or an individual and also
contains some supporting evidence for the truthfulness of that claim. A
credential is commonly submitted to a security service for purposes of
authentication; that is, for a security service to verify and certify that the
identity claim is trustworthy.
The most common example for a credential is a
user-name/password pair. The user-name is a claim made about the identity of the
party seeking authentication. The password is the supporting evidence that the
authenticating service uses to verify that identity. The assumption here
is that
only the party seeking authentication knows about the password and, therefore,
presentation of the correct password (or some value derived from the password
based on an agreed-upon algorithm) is sufficient evidence to prove the identity.
Examples for other forms of credentials are digital
signatures proving possession of a particular certificate, or tokens issued by
third-party security services.
A relying party (or relying service)
provides access to resources or capabilities that will be secured and for which
access will be granted only to authorized requestors. The service therefore
relies on an STS to validate the
credentials of the requestor and directs the requestor through its policy to obtain an assertion
(carried in a token) for
a particular set of claims
from the STS that the relying service might then use for further authorization.
In federated scenarios,
Security Token Services collaborate by trading tokens for other tokens if and
only if the collaborating STS have a mutual trust relationship that allows them
to believe assertions made by the respective other STS. More precisely, an STS
will look at and validate claims asserted by some other STS and will, upon
successful validation, either reaffirm those claims to its relying parties and/or assert additional or even
different claims in the token it issues.
Access Control Service
The Access Control Service is a hosted, flexibly
configurable security token service infrastructure that authenticates
credentials and issues tokens. Each .NET Services solution has a private,
isolated Security Token Service at its disposal. This STS is used as the backing
identity infrastructure for all services published within that solution's
Service Bus namespace, but it can also be used completely independent
of the Service Bus for securing direct connections between endpoints.
For WS-Trust, the Access Control service supports four different
types of credentials: User name/Password, Windows CardSpace, Certificate, and
third-party
STS-issued SAML Token. In addition to supporting the SOAP-based WS-Trust
protocol, the Access Control Service also supports two HTTP-based
mechanisms:
- A simple Web-style HTTP protocol for programmatic access, which issues tokens
for HTTP services based on a preconfigured policy profile und user name/password
credentials.
- A passive requestor mode (which will be WS-Federation
compliant in an upcoming release) through which interactive users are
presented with a choice of supplying Windows CardSpace, User name/Password,
or Windows LiveID credentials when accessing a relayed HTTP service using a
browser.
For all protocols, the authentication of credentials is
based on a validation of supplied credentials against the .NET Services store that holds validation information for Windows CardSpace,
User name/Password, and Windows LiveID credentials for each .NET Services Solution
account. Somewhat special are third-party STS-issued token credentials that
are associated with an account through a trust relationship with the respective
STS.
Upon successful authentication of credentials, the Access
Control
Service can issue a token that either asserts the immediate claims made by the
requestor or issue a set of asserted claims otherwise associated with the
requestor. Whether the Access Control Service will indeed issue a token is, however,
subject to rules configured on the Access Control Service by the account holder. In
other words, even though a credential might be successfully authenticated, the
Access Control Service will refuse issuing a token if the service does not have a rule
explicitly permitting the token to be issued.
The Access Control Service's rule language consists of so-called claim mappings.
A claim mapping maps an authenticated claim (from a user's credentials
or a third-party-issued token) to a claim or a set of claims
that the relying party wants the STS to include in the token.
Architectural Overview: Workflow Service
The Workflow Service is a hosted service
that executes user-defined declarative Windows Workflow Foundation (WF) workflows
built using the .NET Service SDK in a reliable and scalable manner. The
services’ tools and APIs enable you to manage and track the execution of workflow
instances running on the service. It simplifies the need to write complex code
to orchestrate the interactions between services. A .NET Services solution is required to start using the Workflow Service.
The Workflow Service extends Windows Workflow Foundation (.NET Framework
3.5) to the cloud. To build cloud-based workflows, developers can use
the WF Visual Studio designer to author WF workflows using the
set of system-provided cloud-based workflow activities shipped with the .NET
Services SDK. After designing the workflows, developers can upload
their XOML workflows via the Workflow Service portal or the client
APIs. In addition, the Workflow Services portal as well as the client-side APIs provide
user experience and capabilities to run and manage
workflows in the cloud.
System-Provided Cloud-Based Workflow Activities
Using the Visual Studio Workflow designer
capabilities and the set of cloud-based activities found in Microsoft.Workflow.Activities within the
.NET Services SDK, developers can author cloud-based workflows. The following
is the set of cloud-based activities in the .NET Services SDK:
-
CloudDelay: This activity provides the logic to
establish a timer and wait asynchronously for the timer expiration
-
CloudHttpReceive: This activity receives an HTTP request
at the URI
http://workflow.windows.net/workflowsHttp/<UserName>/workflows/<WorkflowTypeName>/instances/
<InstanceId>/<ActivityName> and returns a response.
-
CloudHttpSend: This activity sends an
HTTP request and returns the response.
-
CloudServiceBusSend: This activity sends a message to the Service Bus and returns a
response, if appropriate.
-
CloudXPathRead: This activity
reads the value, specified by an XPath expression, from an XML segment.
-
CloudXPathUpdate: This activity updates
the value, specified by an XPath expression, in an XML document.
Workflow Services Portal
The .NET Services portal is located at
http://portal.ex.azure.microsoft.com/. The
Web site displays the list of workflow types that the user uploaded and the
workflow instances for each workflow type. The Web site exposes UI controls that
enable users to manage the types and manage the instances as well. A simple
workflow instance status is displayed to inform the user about the status of
workflow instances. All workflow management operations on the Web site are
delegated to the workflow SOAP APIs.
More Information
For more information about the .NET Services, see the
following documents in the SDK: