MSDN Magazine - June 2008 - (Page 51)

Notice that the WebHttpBinding endpoint is configured with an instance of WebHttpBehavior, which injects the necessary HTTP-based dispatching logic into the runtime. Once you have the ServiceHost up and running with this new endpoint configured, you can browse to the HTTP URI the service is listening to at localhost:8099/ProductFeed, and you should see the Atom feed. Now suppose we want to expose this feed to salespeople who are not on the internal network. Rather than expose this machine through the fire- Figure 7 Exposing an HTTP Service through BizTalk Connectivity Services wall, we can simply use BizTalk Connectivity Services to relay the HTTP traffic to our local service. of output claims is what’s contained in the token returned by BizWe accomplish this by adding another endpoint using the Relay- Talk Identity Services. When you’re attempting to access BizTalk Binding but specifying RelayedHttp for the ConnectionMode, as Connectivity Services, certain output claims must be present. You can also configure BizTalk Identity Services with a certificate illustrated here: to protect the tokens it produces. When a certificate is configured, ServiceEndpoint se = sh.AddServiceEndpoint(typeof(IPriceUpdateFeed), the token provided to the requestor will be encrypted with the pubnew RelayBinding(RelayConnectionMode.RelayedHTTP), lic key from the certificate, and thus it will be safer traveling on the "http://connect.biztalk.net/services/contososervices/ProductFeed"); se.Behaviors.Add(new WebHttpBehavior()); wire and less susceptible to client tampering in transit. There are a few ways to configure these authorization rules. One With this in place, our service is now securely exposed on the way is through the UI provided on the BizTalk Services Web site public Web, but the logic is hosted on an internal server. In Figure 7, (see Figure 8). The other way is programmatically using the Idenyou can see this feed exposed through a public, Internet-accessible tity Management API found in the SDK. Recently, a RESTful verURI. Of course, the feed looks exactly the same, and now salespeople sion of that interface was also released. When you configure your authorization rules, you’ll want to think on the road can subscribe to this feed and get updates without any about how you are using BizTalk Identity Services. Again, you can complications around VPNs, firewalls, or network issues. use BizTalk Identity Services as a generic STS or as your BizTalk Connectivity Services access control mechanism. Configuring the Identity Services When using BizTalk Identity Services as a generic STS, you can Regardless of the connection mode you use with RelayBinding, both the Listener (service) and the Sender (client) must be authen- map incoming username input claims to any output claim. The ticated and authorized against BizTalk Identity Services. Authenti- output claim will be placed in the resulting token that can then be cation is the process of identifying the client or requestor given an presented to other parties. When using it this way you must have initial set of claims. Authorization is the process of applying a set at least one rule where the input claim is username. You can add more rules that cascade based on new output claims—for example, of user-defined authorization rules on that initial set of claims. The authorization rules simply produce a new set of claims taking the output claim produced by the username rule as the inthrough a series of claim transformations (each rule maps a set of put claim for another output claim—allowing you to build up an input claims to a set of output claims).The initial set of input claims arbitrary set of output claims. See the AccessControl samples in are those presented to BizTalk Identity Services by the requestor. the BizTalk Services SDK for a complete example. In order to authenticate with BizTalk Connectivity Services, you Today BizTalk Identity Services supports three types of initial claim sets: username/password, client certificate, and managed cards. In need to make sure you configure BizTalk Identity Services with a the case of username/password, the username is the initial claim few specific rules. As mentioned, you must have at least one rule where the input claim is username, and you may also have casand the password is the evidence of that claim. BizTalk Identity Services begins processing the authorization rules cading rules. Where BizTalk Connectivity Services is unique, however, is that using the username claim as the starting point to produce output claims. As new claims are produced, they can serve as input claims it will expect to find a Resource#Operation output claim in the final for other rules, allowing for a degree of rule-chaining. The final set token, where the resource must be the service’s listening URI and msdnmagazine.com June 2008 51 http://msdnmagazine.com

Table of Contents Feed for the Digital Edition of MSDN Magazine - June 2008

MSDN Magazine - June 2008 Contents Toolbox CLR Inside Out Cutting Edge Patterns In Practice SAAS Concurrency Robotics Form Filler GUI Library Service Station Foundations Windows With C++ Concurrent Affairs Going Places { End Bracket }

MSDN Magazine - June 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.