Windows Azure AppFabric is a very powerful and important part of
the Windows Azure platform. AppFabric is a set of middleware services
and resources that help you run your applications in the cloud. The AppFabric service bus is one of these
middleware services and provides a connection point across service
endpoints from cloud to on-premises. This bridge helps remote
applications of all types to tie into sites and data that would
otherwise be difficult for them to access.
You can build simple clients and services that are loosely
coupled and that run without any security at all. For example, the following code snippet
creates an instance of a service that uses the
WebHttpBinding class and then sets the
WebHttpSecurityMode to None.
This client instantiation of the service calls the
GetCurrentDateAndTime method to return a string
representation of the current DateTime.Now
object. The service is created without the need to authenticate with
any credentials—and thus acts without the need for explicit claims
about the user:
...
namespace ClientApp
{
class Program
{
static void Main(string[] args)
{
WebHttpBinding binding = new WebHttpBinding(WebHttpSecurityMode.None);
Uri address = new Uri(@"http://localhost/getcurrenttime");
WebChannelFactory<IGetCurrentTime> channelFactory = new
WebChannelFactory<IGetCurrentTime>(binding, address);
IGetCurrentTime myProxy = channelFactory.CreateChannel();
using (new OperationContextScope(myProxy as IContextChannel))
{
string currentTime = myProxy.GetCurrentDateAndTime();
Console.WriteLine("The current time is: {0}", currentTime);
}
((IClientChannel)myProxy).Close();
channelFactory.Close();
Console.ReadLine();
}
}
}
More than likely, you will want to add some measure of
protection to your service and use more than the
WebHttpSecurity.None property. Within the
AppFabric service bus, the Access Control Service (ACS) provides a way to secure the bridged connection
between service endpoints. More specifically, it provides what is
called claims-based authentication for accessing
REST-based services. Although ACS provides the authentication of the
services, the service bus provides the infrastructure to connect them
so that clients and services can connect and be loosely
coupled.
Claims-based authentication (CBA) is not a new concept; the use
of claims for security has been around for a while—though before now
in a more limited fashion. For example, when you log onto your
computer each day, you are providing a claim about yourself: your user name along with a password.
More recently, CBA has become a common way of programming security and
identity into applications (especially cloud-based applications)
because it provides users with a more flexible approach to passing
claims about themselves to and from applications. For example, today’s
CBA applications use Security Assertions Markup Language (SAML)
tokens, which integrate with Active Directory Federation Services (ADFS) 2.0 (which
enables you to collaborate across network boundaries and access applications that are deployed both on-premises
and in the cloud) and other identity providers, such as Windows Live
or Google.
By using ACS security, you can engage in either passive or active authentication, because ACS supports both.
Passive activation uses a user interface such as a browser-based UI
and requires you to register a Security Token Service (STS) with the
web application you’re building. By using ACS, you can create a new
namespace, register an application and identity provider (such as
Windows Live), and then configure your application to use that
identity provider as the STS from your web application. Thus, when
your web applications loads, it redirects to the identity provider,
which prompts the user for the login information and then passes the
user to the application she is trying to access.
ADFS is a federated security model in which
authentication can be mediated through an STS. The STS can issue
SAML tokens that carry claims about the user who is
trying to authenticate against the system. ADFS can require more
configuration and perhaps even code-level security programming, but it
allows the user to authenticate in his or her own domain as well as
gain access to services and applications that reside outside of that
domain by federating their identities to that application domain.
Active and passive authentication, along with the use of claims,
supports a wide range of integration scenarios.
Within the AppFabric service bus, you can use the native claims
that are created when you create a namespace. For example, you created an
on-premises service that used the AppFabric service bus to communicate
with a WCF service that you then deployed to Windows Azure by using a
token and key that was specific to the service bus namespace. Recall
that you needed to first create a unique namespace when interacting
with the AppFabric service bus. Figure 1 shows what the
new service namespace page looks like after you’ve created it. The
important thing to note here is that when you interacted with the
service bus, you used the key name (in this case,
owner) and the management key.
When you implemented the service, you used the service namespace
and the secret key associated with the new namespace to bridge the two
service endpoints—even though one service was running on-premises and
the other was running in the cloud. As a review, the following code
snippet shows the WCF service code that you deployed to Windows Azure
that represented the calling code. Note the use of
svcNmspc and svcBusSecret in
the code; these are then used as core parts of the service bus
credentials and the call to ACS:
...
using Microsoft.ServiceBus;
namespace SharePointCallingSvc
{
[AspNetCompatibilityRequirements(RequirementsMode =
AspNetCompatibilityRequirementsMode.Allowed)]
public class SharePointCallingService : ISharePointCallingService
{
string svcNmspc = "<service namespace>";
string svcBusName = "owner";
string svcBusSecret = "<secret key>
string svcName = "SPListenerService";
public List<Sales> GetSales()
{
Uri svcURI = Microsoft.ServiceBus.ServiceBusEnvironment.CreateServiceUri(
"sb", svcNmspc, svcName);
TransportClientEndpointBehavior svcBusCreds = new
TransportClientEndpointBehavior();
svcBusCreds.CredentialType = TransportClientCredentialType.SharedSecret;
svcBusCreds.Credentials.SharedSecret.IssuerName = svcBusName;
svcBusCreds.Credentials.SharedSecret.IssuerSecret = svcBusSecret;
NetTcpRelayBinding binding = new NetTcpRelayBinding();
ChannelFactory<ISalesDataChannel> channelFactory = new
ChannelFactory<ISalesDataChannel>(binding, new EndpointAddress(svcURI));
channelFactory.Endpoint.Behaviors.Add(svcBusCreds);
ISalesDataChannel channel = channelFactory.CreateChannel();
channel.Open();
List<Sales> listFromOnPrem = channel.GetSales();
channel.Close();
return listFromOnPrem;
}
}
}
ACS, which is used as part of the core security service within AppFabric, is also quite
flexible. For example, in this application code, you’re mapping
service endpoints through a token and key; what if you want to provide
some level of passive authentication? Or further, what if you want to
incorporate OAuth (which is an open security protocol that uses
existing security infrastructure such as Windows Live ID or Yahoo ID)
to help provide a security layer into your applications? With ACS,
this can absolutely be done.
