Azure – Microsoft .NET Services- Step 01 – The Service Bus – Blog Post about Setup

 

Azure – Microsoft .NET Services- Step 01 – The Service Bus – Blog Post about Setup

  • Comments 1

 

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

http://www.microsoft.com/azure/trainingkit.mspx

 

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.

Connect Applications

  • 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.

Composite Applications

  • Applications frequently need to connect or integrate with other applications and services to create what are called composite applications.

Significant Challenges

  • 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.

Workflow

  • 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.

Security Options

  • 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.

 

CredentialType Value

Description

CardSpace

The client credential is a self-issued Windows CardSpace information card that is registered with the .NET Access Control Service.

AutomaticRenewal

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.

FederationViaCardSpace

The client credential is a managed Windows CardSpace information card issued by an identity provider trusted by the .NET Access Control Service.

UserNamePasssword

The client credential is a username/password credential for the .NET Service Bus solution registered with the .NET Access Control Service.

X509Certificate

The client credential is a X.509 certificate for the .NET Service Bus solution that has been registered with the .NET Access Control Service.

Unauthenticated

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

System Requirements

You must have the following items to complete this lab:

•    Microsoft Visual Studio 2008

•    Microsoft .NET Framework 3.5

You also need administrator privileges.

Certificates

X.509 certificates are needed for the lab exercises

How certmgr.exe works

How makecert.exe works

Installing SDKs

You will need to install the .NET Services SDK

Certificates

X.509 certificates are needed for the lab exercises

 

Azure Services Toolkit

The purpose of this blog post is to help understand the Hands-on Labs in more detail.

Downloading Resources

There are several useful downloads at http://www.microsoft.com/azure/sdk.mspx

Here are just a few:

 

Hands-On Lab - .NET Services: Introduction to the .NET Service Bus – Setup

Let's start with the certificates to begin the process.

 

Certificates

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:

  • Claims-based access management and Identity federation
  • Interoperable & based on standard protocols (X.509 and SAML)
  • Supports CardSpace, LiveID, Username/Password

 

 

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

CertMgr.exe

-r

currentUser indicates that the certificate store is under the HKEY_CURRENT_USER key. This is the default

-s

Indicates that the certificate store is a system store. If you do not specify this option, the store is a StoreFile.

My

System store is called My

-c

Deletes certificates is used with the –del

-n

Common name of certificat. In this example, client.com

 

Notice

Two registry locations (CurrentUser & LocalMachine)

Two System stores (My & TrustedPeople)

 

Create new certificates

MakeCert.exe

-sr

Specifies the subject's certificate store location. Location can be either currentuser (the default), or localmachine.

-ss

Specifies the subject's certificate store name that stores the output certificate.

-a

Specifies the signature algorithm. Must be either md5 (the default) or sha1.

-n

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".

-sky

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.

-pe

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

 

C:\AzureServicesKit\Labs\IntroServiceBus\Setup>cscript setupex.vbs

 

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

http://www.microsoft.com/azure/servicebus.mspx

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

http://www.microsoft.com/azure/register.mspx

Now we are ready to start writing some applications…

 

 

 

 

  • Thank you for submitting this cool story - Trackback from progg.ru

Page 1 of 1 (1 items)
Leave a Comment
  • Please add 6 and 7 and type the answer here:
  • Post