Introduction - Getting Setup
This blog post is all about getting ready to learn about .NET Services, and the Service Bus specifically. This blog is based on the Azure Services Toolit and adds additional background information.
The training kit can be downloaded at
Brief Intro about .NET Services - What is .NET Services and why should we learn it?
· Microsoft .NET Services are a suite of web services for customers with integration and business-to-business collaboration requirements; the services offered include workflow, access control, and service bus connectivity, and all run from the Azure Services Platform.
· The Service Bus makes it easy to connect applications together over the Internet.
· Services that register on the Bus can easily be discovered and accessed, across any network topology.
Similar to Enterprise Service Bus
· The Service Bus provides the familiar Enterprise Service Bus application pattern, while solving some of the hard issues that arise when implementing this pattern across network, security, and organizational boundaries, at Internet scale.
· Applications frequently need to connect or integrate with other applications and services to create what are called composite applications.
· Creating an infrastructure to facilitate this type of communication involves significant challenges related to authentication, naming, and secure cross organizational firewall traversal.
· The .NET Service Bus provides a hosted, secure, standards-based infrastructure that dramatically reduces the barriers to applications communicating across systems and organizational boundaries.
.NET Services is about getting past firewalls and NATs
· The Service Bus service enables secure connectivity between services and applications behind firewall or network boundaries, facilitating cross-organizational communication.
· Additionally the service bus allows service functionality to be exposed easily and consumed from other applications in a loosely coupled manner using a variety of communication patterns.
· The Workflow service simplifies the need to write complex code defining a business process, offering a way to coordinate service and application interaction with pre-written activities that can be composed together to create a workflow.
Certificates are needed for the Access Control Service
· The Access Control service provides an enterprise-class mechanism for enforcing access control rules and authorization as a web service.
· It supports federated scenarios to support enforcement of access control rules where users may come from multiple organizations or utilize different identification protocols.
· You can use Windows CardSpace information cards, X.509 certificates, username/password credentials, or no credentials at all.
There are numerous SDK samples that illustrate these different credential options.
The client credential is a self-issued Windows CardSpace information card that is registered with the .NET Access Control Service.
The client credential is a self-issued Windows CardSpace information card that is registered with the .NET Access Control Service. The difference is the access token will be automatically renewed as needed.
The client credential is a managed Windows CardSpace information card issued by an identity provider trusted by the .NET Access Control Service.
The client credential is a username/password credential for the .NET Service Bus solution registered with the .NET Access Control Service.
The client credential is a X.509 certificate for the .NET Service Bus solution that has been registered with the .NET Access Control Service.
No client credential is provided.
Some Key Points about certificates and authentication
· X.509 certificates work with the .NET Access Control Service through the Azure Services Platform portal.
· Once you've registered a Windows CardSpace information card or X.509 certificate with a solution, you can use it for authentication.
· You can also control whether or not clients are required to authenticate with the .NET Service Bus by configuring the binding for the receiver.
· You do this through the relayClientAuthenticationType property on the <security> element supported by each relay binding.
· If you set the property to "None", clients will not be required to authenticate in order to relay messages to the receive.
· So the .NET Service applications we create, like any other claims-based application, needs to have its own X.509 certificate that the Access Control Service can use for encrypting the security tokens that the service will receive.
Table of contents for this blog post
Downloading of resources
This includes SDKs and the training kit
Hands-On Lab - .NET Services: Introduction to the .NET Service Bus - Setup
This is discussing the setup of the lab exercise
You must have the following items to complete this lab:
. Microsoft Visual Studio 2008
. Microsoft .NET Framework 3.5
You also need administrator privileges.
X.509 certificates are needed for the lab exercises
How certmgr.exe works
How makecert.exe works
You will need to install the .NET Services SDK
Azure Services Toolkit
The purpose of this blog post is to help understand the Hands-on Labs in more detail.
There are several useful downloads at http://www.microsoft.com/azure/sdk.mspx
Here are just a few:
Let's start with the certificates to begin the process.
One of the first things you will need to get up and running is some certificates, so that you can get the appropriate X.509 certificates to do some of these lab exercises. ...). If you need security, WSHttpBinding is another solution, but you will have to give your users some kind of credentials (Username/password, certificate...) to use your service.
Azure Access control works with .NET Services. It provides:
A certificate creation tool is used to generate and store in the local machine X.509 certificates.
We will use a certificate creation tool to generate and store in the local machine X.509 certificates.
The folder = C:\AzureServicesKit\Labs\IntroServiceBus\Setup
The script to execute = SetupEx.vbs
Delete Existing certificates
currentUser indicates that the certificate store is under the HKEY_CURRENT_USER key. This is the default
Indicates that the certificate store is a system store. If you do not specify this option, the store is a StoreFile.
System store is called My
Deletes certificates is used with the -del
Common name of certificat. In this example, client.com
Two registry locations (CurrentUser & LocalMachine)
Two System stores (My & TrustedPeople)
Create new certificates
Specifies the subject's certificate store location. Location can be either currentuser (the default), or localmachine.
Specifies the subject's certificate store name that stores the output certificate.
Specifies the signature algorithm. Must be either md5 (the default) or sha1.
Specifies the subject's certificate name. This name must conform to the X.500 standard. The simplest method is to specify the name in double quotes, preceded by CN=; for example, "CN=myName".
Specifies the subject's key type, which must be signature, exchange, or an integer that represents a provider type. By default, you can pass 1 for an exchange key and 2 for a signature key.
Marks the generated private key as exportable. This allows the private key to be included in the certificate.
Here is the command you will execute
If all goes well, you will see:
Next, the setup process will try to install some snippets to help with the programming side of the labs.
You may see a security warning. Simply hit "Yes" and continue to hit "Next" until you finally get the "Finish."
The final screen will look like this:
Downloading and Installing the Microsoft .Net Services SDK
Download the .NET Services SDK (currently the latest is March 2009)
Continue to hit "Next" until you hit finish.
This concludes the installation of the .NET Services SDK
Make sure you have an account with Azure
Now we are ready to start writing some applications.
PingBack from http://microsoft-sharepoint.simplynetdev.com/azure-microsoft-net-services-step-01-the-service-bus-blog-post-about-setup/
Thank you for submitting this cool story - Trackback from DotNetShoutout