Introduction_to_.NET_Services

+1

No comments posted yet

Comments

Slide 2

.NET Services is a key part of Microsoft’s cloud strategy. Microsoft has been working on .NET Services for a long time. It was formerly an incubation project called BizTalk Services (not to be confused with BizTalk Server). This has been retired and completely replaced by .NET Services. .NET Services provides a set of cloud-based building block services. Specifically it has a Service Bus and an Access Control service. Microsoft will be adding to these services over time. In particular, there will be a workflow service based upon Windows Workflow Foundation 4.0. In CTPs prior to the July CTP .NET Services included a Workflow Service based up Windows Workflow Foundation 3.5 – the currently shipping version of WF – but customers said they’d prefer to wait until a 4.0-based version was available. Microsoft is very interested in hearing which services you would like to see included. In this presentation we’re going to cover the services available in the current CTP and that will ship as part of the .NET Services v1 at PSC 2009: the Service Bus and Access Control

Slide 3

The primary motivation behind .NET Services was to take the existing .NET technologies and development environment and extend them to the cloud. The goal being to make the transition to cloud development very simple for existing .NET developers, giving them all the benefits of running in the cloud with minimum effort. Examples include sending messages between enterprises through WCF and handling claims-based identity to do authentication and authorization. By providing such services in the cloud we can provide internet scale and simpler deployment and management. For example, configuring, managing and maintaining federated identities on-premise can be complex, time-consuming and error-prone. Instead of buying and maintaining servers you can use servers in the cloud, running in Microsoft data centers. You access the services via a portal, via standard protocols and via a simple and familiar programming model. Regarding openness and accessibility: something Microsoft has heard consistently and repeatedly from customers is that they don’t want to be limited to one technology or platform, so with .NET Services we use open, standard protocols such as HTTP, REST and SOAP. However, with .NET Services we’re actually going one step further in that we’re providing SDKs as open source projects for Ruby and Java. We’ve not done this before. The key challenges we’re addressing with the current bits are app integration with the ServiceBus and federated identity through the access control service. This talk is going to cover each of these services at a high, architectural level. We’ll go deeper into the individual services later on.

Slide 4

A common issue we see is that the Internet has enabled connectivity between partners and we need to make access to partner applications easy and secure. At the same time we don’t always know the characteristics of the application: the platform, how much it needs to scale. There are also topology issues, connectivity issues with firewalls and NATs that can get in the way of application integration. To address these issues, we took the concept of a Service Bus, as applied in the Enterprise as an Enterprise Service Bus, moved it into the cloud and made an Internet Service Bus for doing application integration.

Slide 6

Rather than being a product per se, a Service Bus is a pattern. Let’s see how that pattern is actually implemented. The Service Bus consists of a naming, service registry and messaging fabric connected to a federated identity and access control piece. Collectively, this is a “Service Bus”. It can connect clients to services, both on-premise and in the cloud, plugging everything together in a loosely-coupled way. This works in a very similar way to an Enterprise Service Bus which connects internal corporate services together. Indeed the Internet Service Bus can be used to connect internal services, external services and internal ESBs. In order to be loosely-coupled we need 3 things: 1) consistent naming, 2) federated access control, 3) loose-coupled messaging to those clients and services connected to the Service Bus.

Slide 7

The connectivity fabric enables you to connect applications very simply, regardless of where they are located. Using the Service Bus, messages can traverse NATs and firewalls, connecting to all kinds of apps: in the cloud, in the data center, at home or on an intermittently connected mobile device. All kinds of messaging patterns are supported. The Service Bus enables: Bi-directional communication even though you might be behind a firewall. It enables peer-to-peer communication, such as with Instant Messenger, where, once apps are connected via the Service Bus, a very efficient direct connection can be made between parties. Publish and subscribe where hundreds or thousands of apps can send and receive messages via common URI endpoints. Storing and forwarding of messages to allow for intermittent connectivity and for HTTP-based, stateless and connection-throttled apps. Apps come along and pick up messages when needed. The Service Registry is the very simple URI-based directory of names which describe how applications connect to the bus. You can access and browse the registry by using WS-Discovery and the Atom Publishing Protocol.

Slide 8

For applications to integrate across many organizations and topologies it’s best to have stable human-readable names to describe the services connected to the system. Whereas Tibco and other service buses tend to use proprietary naming schemes, we use URIs because they are the standard way to name things on the Internet. The Service Registry is pretty simple: there is a root with either http or sb (REST or SOAP), followed by servicebus.windows.net/services, then whatever account name you’re using and then the naming scheme of your choice under your account. This general purpose, multi-tenant naming convention enables anyone - not just Microsoft - to have their own roots and anyone can connect to any number of services within that namespace.

Slide 9

Securely connecting applications across organizations via the Internet is very difficult and time-consuming. The Service Bus provides you with the simplest and most secure way of doing just that. It incorporates security best practices, operates with a minimal impact on firewalls, and allows the IT department to have the control it requires. There are three key connection capabilities: the Relay, Direct Connections and storing and forwarding of messages. The relay is the rendezvous point in the sky between clients and services. It ensures applications can connect, using the service registry to describe endpoints. A message goes from one application through the relay and to other listening applications. Although the relay ensures applications can connect, you don’t necessarily want all the messages to go through the bus. Firstly, the performance will be better with a direct connection and secondly, there will be a cost associated with using the bus. What you can do is use the service registry and the service bus for apps to locate each other and establish an initial connection, after which a direct connection can be established, traversing firewalls and NATs by utilizing some pretty sophisticated heuristics (these typically work about 80% of the time but we are still improving this). Commonly people want a binary bi-directional channel between their endpoints. By default, applications need to be connected to the Service Bus and listening to “connection points” to receive messages. However, we can create long-lived queues on the ServiceBus so that an app can simply retrieve messages the next time it connects rather than being connected all the time. Routers forward messages from one or more publishers to one or more subscribers. Publishers and subscribers can connect to routers using HTTP, HTTPS, or the Service Bus "NetOneway" protocol. Messages are pushed down to the subscribers and can be queued until a subscriber is online. Everything on the bus is available via HTTP and REST as well as SOAP. The Service Registry is exposed as an ATOM feed. The Service Bus is accessible via WCF using a set of bindings very similar to the classic WCF bindings making it very simple for the WCF developer to modify an application to use the Service Bus by tweaking the WCF configuration.

Slide 10

The most basic functionality of the bus, upon which everything else is based, is a one-way connection between a sender and a receiver. The receiver needs to open an outbound SSL-secured connection to a relay rendezvous endpoint. The default connection is outbound TCP port 828 which works well with the vast majority of firewalls without exposing systems to risk. Once made, the TCP connection is held open. Then the sender can open an outbound connection to the same relay node and send a message which is forwarded down to the receiver. There are lots of variations on this but this is the simplest use case.

Slide 11

With Direct Connections, once the connection is opened and the sender can talk to the receiver, logic on both the sender and receiver sides determines, out-of-band via the relay, what the actual locations is of the other party - i.e. the IP address and their outbound connectivity port(s) - and then it attempts to patch a TCP channel between them. If it succeeds there is a direct, high performance connection. NATs, firewalls and routers often allow this kind of connection (not always though). You can control the exact behaviour you want: e.g. use the relay first and then auto-upgrade, or fail if no direct connect is possible (check CTP notes for current behaviour) .

Slide 12

We’ve talked about the service registry (names), about the relay (connectivity) and about direct connections (high performance communication). On top of this we provide the other capability of a classic service bus, namely publish and subscribe. There might be a lot of applications that are interested in a particular event such as the sale of a stock. You publish this event to a “topic” and then anyone who’s interested in that topic – in different organizations and companies – can listen in to that topic and you get fan out capabilities without having to write logic at the send point for each and every one of your partners. The service bus registry name, as an outbound communications node, is the topic. Anyone listening on that node will receive messages. This is the lowest level of pub/sub, referred to as connected multicast. In other words, messages are multicast to everyone currently connected to the node. If you’re not connected you don’t get the message. As of the March 2009 CTP of .NET Services, you can use queues and routers. A combination of these enables you to easily provide store and forward semantics. Queues can store messages while a receiver is offline and routers can forward those messages to any desired endpoint.

Slide 13

This is how pub/sub works using multicast semantics. Logically, when the sender sends the message we iterate through the set of listeners on the endpoint node and forward the message to each of them. Physically, we may have 10s of 1000s of subscribers geo-distributed across the world. We don’t just have it on one computer, there is a fabric of thousands of computers and a sophisticated ringed routing system enabling high availability fan out.

Slide 14

You create a queue policy document describing the kind of queue you want and send it to the Service Bus using the ATOM Publishing Protocol. Once created, a sender can send messages into that queue and a receiver can either destructively or non-destructively read from the queue.

Slide 15

Routers have a router policy which is again uploaded to the cloud using AtomPub. One or more receivers can then subscribe to that router and have messages pushed down to them. By using a combination of queues and routers you can achieve many different pub/sub patterns with multiple senders, multiple receivers, using different transports (HTTP/HTTPS/TCP) and message formats (SOAP 1.1/1.2/plain), with messages being routed to subscribers as and when they become available.

Slide 17

For those familiar with WCF, there are a set of Service Bus bindings in the .NET client SDK that, as you can see, are closely related to the existing WCF bindings. This makes it easy for the WCF developer to use the Service Bus and to modify existing applications to use the Service Bus by switching the binding (you’ll probably need to change the security credentials to go across organizations).

Slide 18

What do we do with, say, Java clients in very constrained corporate environments? SSL over outbound port 828 might not possible either because your IT admin won’t let you do it or your programming environment might make it difficult (e.g. Perl, Python, Ruby). RFC 2616 limits us to a maximum of two concurrent connections over HTTP which can starve access… <this slide and the next slide are deprecated as queues and routers now provide this functionality>

Slide 19

To address this, the Service Bus can create a simple volatile message buffer (on one machine) which collects responses and multiplexes them down. The Java libraries use this. There is a single-threaded polling receiver and multiplexed dispatch mechanism. The next step is to make these volatile buffers durable so that we have store and forward. This should be in the next milestone for the Service Bus.

Slide 20

All communication through the Service Bus is controlled by the Access control service. To send and receive messages on the bus you have to have the right permissions. The Service Bus composes properly with standard SOAP over HTTP semantics including end-to-end (multiple) WS-Security headers which allows encryption and signing of the message (unlike some web services stacks ). In other words, the Bus just sees the routing headers, the message is opaque. Furthermore, this composes with transport-only message protection. If desired, an organization can set up an endpoint with their own security mechanism. At the same time, an access control check can be made at the time a message is submitted to the service bus. This is very interesting as messages without the right permissions are filtered out before the get to an application, mitigating a whole range of buffer overflow and DoS attacks before the app is called.

Slide 21

Despite all of the security features we have, one of the most requested features from customers was also to have unauthenticated senders. They want to set up an http endpoint that anyone can send to (provided it meets the right message characteristics). This allows them to run an anonymous service, e.g. a web server, without exposing an IP address, allowing them to move it around. You can then have a web site or web service endpoint within a corporation and have http requests routed to it (e.g. a web site on your laptop ).

Slide 23

One of the biggest challenges people face is the sheer complexity of handling cross-organizational identity, especially considering all the different vendors that play in this space. This means there is often an enormous test matrix and typically there is a lot of spaghetti code dealing with identity within applications. This is very tough to maintain. If we can factor out access control logic from the application code base we’d be in a much better position. IBM and Whale are doing this, Microsoft does this with the access control service. Again, it’s 100% built upon standards such as WS-Federation, WS-Trust and SAML. There are also some new .NET Framework pieces that make it easy to handle identity, namely the Geneva Server and Framework.

Slide 24

This is the basic interaction pattern for access control. The Relying Party is your application. The Access Control instance (project) is a hosted security token service. The customer wants access to your application. First you exchange certs - or symmetric keys - to establish a trust between the access control project and the RP. This key enables the signature on a message to be verified. Next we define some access control rules, that can be arbitrarily complex, using a set of input claims and a corresponding set of output claims. The requestor sends a set of claims to the Access Control project then, based upon the defined rules, the Access Control Service returns a set of output claims in a token to the requestor which is then sent to the RP. The requestor gains access based upon what the RP will allow for a requestor with that claim set. For example, incoming claims might state that the requestor is a manager in the accounting department at Toyota. This maps to an output claim of administrator access for a particular app and when that claim is presented to the app the requestor is authorized appropriately. This process uses WS-Security, WS-Trust, SAML and we’re also looking at things like OAuth and OpenID.

Slide 25

You can set up rules using the portal or through a set of web APIs. As part of that you define an application scope. A single .NET Services solution can be used with many different applications. Since each application is likely to need a different set of claims (e.g. a finance app might need a credit limit claim, an HR app might need a supervisor claim) we can partition rule sets into different application scopes and delegate access to those scopes. We define access control rules with a specific scope, each rule having a set of input claims mapped to a set of output claims. Rules can be chained so that the output claim of one rule might be the input claim of another. You can also define claims and claim types, manage signing and encryption keys. Everything is standards compliant and will work with many web services and identity stacks.

Slide 27

This example shows how to control access to a target service and to the Service Bus itself. The client wants to access a target service via the service bus. To do this, it reads the policies associated with the various endpoints in the system. It will then use that information to request an identity provider for the token and claims that it needs. Currently, the access control service can act as an identity provider (i.e. it has an identity store) but this can be any WS-Trust compliant identity provider, such as Geneva Server. Once it has a claim set in a token it sends that to the access control service where the rules are run for the target service’s application scope and a signed token containing the output claims is returned to the client. The message has a WS-Security header for the target service and a relay token header for the service bus. The former allows signing and encryption for the target service, the latter says that the client has the rights to use the service bus. All of these headers are composed very easily.

Slide 1

Microsoft Developer User Group - Hyderabad Introduction to .NET Services “ Sharing is our Passion “

Slide 2

Introduction to .NET Services Nithin Mohan T K Technology Specialist / Member Microsoft Developer UG – Hyderabad Blog… www.nithinmohantk.info Mail… nithinmohantk@nithinmohantk.info

Slide 3

.NET Services Extending .NET technologies to the cloud Open and accessible REST, SOAP, RSS, Atom Publishing Protocol Class libraries for .NET, Java and Ruby Easy-to-use from .NET Your skills move forward Initial focus on two key developer challenges Application integration Access control in a federated world

Slide 4

Service Bus Key developer challenges Want to make it easy and secure for partners to use your application Don’t always know the characteristics or scale of the integration Partners, customers & users have devices and services running behind firewalls Approach Provide a high-scale, highly-available “Service Bus” that supports open Internet protocols

Slide 5

Service Bus The Internet Service Bus pattern Service Registry Connectivity (Relay & Direct Connect) Publish/Subscribe “Under the Hood” Bindings Integration with Access Control

Slide 6

The Service Bus Pattern Service Registry Applications Federated Identity and Access Control Clients Cloud Services On-Premises Desktop, RIA, Web Desktop, RIA, Web Web, Desktop, RIAs, … Corp Service Your Services Application Messaging Patterns Connectivity Fabric ESB

Slide 7

Service Bus Capabilties Service Registry Stable URIs for services Discovery – supports the Atom Publishing Protocol Connectivity Fabric NAT and firewall traversal Mobile and intermittently connected receivers Application Messaging Bi-directional and peer-to-peer communication Publish and subscribe Multicast to receivers through a stable URI Message buffering Web integration, queues and routers

Slide 8

Service Registry [http|sb]://solution.servicebus.windows.net/accounts/svc/… Root solution. servicebus .windows. net accounts contoso … svc Service Registry Root Multi-Tenant The service registry provides a mapping from URIs to services

Slide 9

Connectivity Key capabilities Relay Ensure applications connect Direct connect Shortcuts for efficiency Queues and Routers Messages can be stored and forwarded Available via HTTP, REST and ATOM Available in .NET via WCF Bindings

Slide 10

Relay One-Way Connection sb://solution.servicebus.windows.net/service/endpoint Sender Receiver Outbound SSL-Secured TCP 828 Connection to Relay Rendezvous Endpoint One-Way Messages through TCP Tunnel

Slide 11

Relay sb://solution.servicebus.windows.net/service/endpoint Direct Connections Sender Receiver - Outbound SSL-Secured TCP 828 Connection to Relay - Out-of-Band Protocol to negotiate Direct Connection Upgrade to Direct when possible

Slide 12

Publish/Subscribe Builds on the relay and direct connect connectivity capabilities “Connected multicast” for current listeners Or can use queues and routers to get long-lived, “store and forward” message routing

Slide 13

Relay sb://solution.servicebus.windows.net/service/endpoint Basic Publish/Subscribe Sender Receiver Outbound SSL-Secured TCP 828 Connection to Relay Rendezvous Endpoint One-Way Messages through TCP Tunnel Receiver Receiver Receiver

Slide 14

Queues Service Bus Sender Receiver sb://solution.servicebus.windows.net/a/b/ Backend Naming Routing Fabric Frontend Nodes Dequeue Route Manager

Slide 15

Routers Service Bus Sender sb://solution.servicebus.windows.net/a/b/ Backend Naming Routing Fabric Frontend Nodes Route Manager Receiver Subscribe

Slide 16

Service Bus The Internet Service Bus pattern Service Registry Connectivity (Relay & Direct Connect) Publish/Subscribe “Under the Hood” Bindings Integration with Access Control

Slide 17

Rich Set of Connectivity Bindings

Slide 18

Relay RFC2616-Compliance http://solution.servicebus.windows.net/service/endpoint Sender Receiver RFC2616 compliant HTTP stack Only 2 concurrent connections per domain 2 concurrent polling clients starve dual reply-to path

Slide 19

Relay http://servicebus.windows.net/services/user/service/endpoint HTTP Connection Workaround Sender Receiver Single-threaded polling receiver; multiplexed message batch retrieval; MT local dispatch and fan-out Multiplex messages through volatile message buffer for pickup STA Synchronized reply-to connections

Slide 20

Relay Access Control Principles Access Control is governed by Access Control Rules Composes cleanly with SOAP-over-HTTP SOAP 1.1, SOAP 1.2 HTTP clients able to send messages through the relay with minimal extra effort WS-Security header can used for end-to-end application level security - optional Composes cleanly with transport-only message protection Support any SOAP 1.2 Basic Profile 2.0 compliant client

Slide 21

Unauthenticated Senders Unauthenticated ‘Send’ option Client do not need to acquire tokens for communicating through the relay Supports plain Basic Profile SOAP requests Opt-In Policy set by listening services Enables services to choose between Relay-based access control and locally-enforced end-to-end access control

Slide 22

Service Bus Summary Service Registry Relay and direct connect connectivity Publish/Subscribe Integrated with Access Control services

Slide 23

Access Control Key developer challenges Many identity providers, many vendors, many protocols, complex semantics – tricky to get right Application strewn with one-off access logic Hard to get right, not agile, not compliant, many dead ends Approach Automate federation for a wide-range of identity providers and technologies Factor the access control logic from the application into manageable collection of rules Easy-to-use framework that ensures correct token processing

Slide 24

Access Control Interactions Your Access Control Instance (a hosted STS) Relying Party (Your App) 2. Send Claims 4. Send Token (output claims from 3) 5. Send Message w/token 0. Certificate exchange; periodically refreshed Requestor (Your Customer) 1. Define access control rules for a customer 6.Claims checked in Relying Party 3. Map input claims to output claims based on access control rules

Slide 25

Hosted Security Token Service Web Portal and API Define and manage Application scopes, access control rules, claim types, signing and encryption keys Access control rules Rules are defined within an application scope Rules can be chained e.g. bob  manager, and manager  allowed Simple model: the output security token is a collection of claims based on the claims in the incoming token

Slide 26

Standards The Access Control Service is fully standards compliant WS-Trust and WS-Federation, SAML A .NET application can easily handle the tokens and claims from the Access Control Service Windows Identity Foundation (aka Geneva Framework) provides a .NET API for doing this Microsoft has been working with vendors such as Sun and Tivoli to make sure everything works correctly on other platforms

Slide 27

Target Service AC.W.N STS Client RST/RSTR AC.W.N Credential appliesTo: Target Endpoint Relay and End-to-End Security Relay P P Requires AC.W.N Token AC.W.N Credential appliesTo: Relay Endpoint WS-Sec Hdr P AC.W.N Credential appliesTo: Relay Endpoint relayToken WS-Sec Hdr

Slide 28

Access Control Summary Flexible, rules-driven access control Rich support for a wide range of identity providers Easy to incorporate into existing applications Works with lots of other environments e.g. Sun’s Java Metro 1.3

Slide 29

Call to Action Go to the.NET Services Portal https://portal.ex.azure.microsoft.com/ Create some solutions Try out the .NET Services SDKs Go to http://www.microsoftpdc.com to get in depth sessions Service Bus Access Control

Slide 30

Q & A

Slide 31

Visit my blog @ http://www.nithinmohantk.info Thank you all Visit our website http://www.hyderabadtechies.info

URL:
More by this User
Most Viewed