During the last year I worked almost exclusively on this. Kidozen, the world’s best cloud-based platform for building mobile applications with enterprise capabilities.

Now, after a very successful private beta period we are announcing public availability. I’ll go deeper on what kidozen is and why is the world’s best cloud-based enterprise mobility platform, but I’d like to start talking about the experience of building this amazing product.

First of all I have to say that this is the kind of product in which I always wanted to work on. Why? Well, first because Kidozen is a platform for developers: APIs, SDKs, services and tools that developers will use, and second because is cloud-based and cloud computing is one of my favorite topics. Also, as you can imagine, build a whole cloud-based platform requires a lot of engineering work which was very interesting and enriching to do.

Kidozen’s core was built using Node.js and a bunch of cloud services, so you can imagine how “cloud” is it’s spirit. We built the whole platform from scratch, it took a lot of effort and it could only have been done by a talented team like the Tellago Studios team. At this point I want to thank to the whole team: Gustavo, Silvio, Christian, Soledad, Jose (that is not here anymore but devoted a lot of effort to the project and put in place many of the cornerstones of it) and Jesus (the man with the vision) for the tremendous talent, the passion, the work over nights and basically for let me share with them this amazing experience that was building Kidozen.

What is Kidozen?

Imagine that you are a company that needs to build mobile applications for your employees or your customers. You will need to resolve things like data storage, logging, notifications, configuration etc. You also will need to resolve how to secure your data, maybe using your company directory credentials, Active Directory for example,  outside of the boundaries of your company or your Google Apps account. And what about distribute those apps? and manage them?. Well, Kidozen is here to solve all those problems for you.

Now, I’ve said that Kidozen is the world’s best cloud-based platform for doing enterprise mobility, why? because Kidozen not only provides data storage, push notifications, messaging, sms, email, configuration, logging, queues and many other backend services in a simple and secure way, it also provides an standard way of build, manage and distribute you company mobile applications.

We give you an app-centric model in which you have all those services isolated and ready to use with a single line of code, in a secure way using your company credentials (Active Directory) or web providers like Google, Yahoo, Facebook, etc…

We also provide a marketplace for your company that allows you to centralize the distribution of your applications, a management portal where you can create, manage, configure and publish your applications and SDKs for all the popular mobile platforms: Windows 8, iOS, Android and we also have a JavaScript SDK and hosting for HTML5 applications.

Why is the best one for developers? let me say it in this way, this is all the code you need to authenticate your Android users against your company AD, outside of your LAN:

kido.Authenticate("John Smith", "P@ssw0rd!", authCallback);

And this is all the code you need, to authenticate against your partner AD in the same application:

kido.Authenticate("Partner AD", "John Smith", "P@ssw0rd!", authCallback);

Or this is all the code you need to send push notifications trough all your iPhones or iPads:

id notification = [kido pushNotifications];
[notification pushNotification:@"Kidozen Rocks!" InChannel:@"kidoChannel"];

Did you get that? It is really simple but at the same time powerful.

Why is the best one for architects? Because it provides a simple, unified and standard way of building all you company applications, the final result is more maintainable and standardized applications.

Why is the best one for managers? Because now, with Kidozen, you can apply all your workforce in to build feature-rich business applications without having to spend time in to solve technical problems.

So that is Kidozen, our way of democratize enterprise mobile applications development. Give it a try!

Next steps

We are already working on the next version of Kidozen, expanding one of our key features “Line of Business APIs”, with this feature you will be able of integrate your on-premise services with your mobile applications in a secure way, with a single line of code.

If you want more information about kidozen don’t hesitate in to contact us!

If you want to know how this works you can see the detailed explanation here. Also you can find the source code on my github: https://github.com/leandrob/wstrust-client

Installation

$ npm install wstrust-client

How to use it

var trustClient = require('wstrust-client');

trustClient.requestSecurityToken({
    scope: 'https://yourapp.com',
    username: 'Your Username Here',
    password: 'Your Password Here',
    endpoint: 'https://your-ws-trust-endpoint-address-here'
}, function (rstr) {

    // Access the token and enjoy it!
    var rawToken = rstr.token;

    console.log(rawToken);

}, function (error) {

    // Error Callback
    console.log(error)

});

Remember that if you are using ADFS, the endpoint that you need to use is: /adfs/services/trust/13/UsernameMixed.

Hope be useful!

As you probably know ACS or Windows Azure Active Directory has an OData API for manage Identity Providers, Relying Parties, Rules, etc, as a requirement in the project that I’m working on we needed to use that, so together with my teammate Gustavo Machado we build this nice Node.js module that allows to do that in a very simple manner.

You can find it on my github: https://github.com/leandrob/node-acs-cli

Installation

$ npm install acs-cli

How to use it….

var ManagementClient = require('acs-cli');

var client = new ManagementClient('[acsNamespace]', '[acs-management-key]');

client
        .from('RelyingParties')
        .top(2)
        .query(function (err, res) {
            ///res...
        });

Hope be useful!

One of the outcomes of that work is a book called “Building Elastic and Resilient Cloud Applications”. This book provides background information on autoscaling and transient fault handling which makes it useful even if you don’t want to use the Application Blocks.

The P&P guys sent me a copy of the book as a gift and they mentioned my name on the list of advisors. I am very proud and thankful of have participated in this project.

You can find the details on MSDN clicking here.

Due to I’ve received a lot of requests on the subject, here’s the code to do the same but using username and password, I mean request tokens from ADFS 2.0 using username and password based identity.

var stsEndpoint = "https://[server]/adfs/services/trust/13/UsernameMixed";
var relayPartyUri = "https://localhost:8080/WebApp";

var factory = new WSTrustChannelFactory(
    new UserNameWSTrustBinding(SecurityMode.TransportWithMessageCredential),
    new EndpointAddress(stsEndpoint));

factory.TrustVersion = TrustVersion.WSTrust13;

// Username and Password here...
factory.Credentials.UserName.UserName = user;
factory.Credentials.UserName.Password = password;

var rst = new RequestSecurityToken 
{
    RequestType = RequestTypes.Issue,
    AppliesTo = new EndpointAddress(relayPartyUri),
    KeyType = KeyTypes.Bearer,
};

var channel = factory.CreateChannel();

SecurityToken token = channel.Issue(rst);

I hope you find it useful!

Request for a Security Token

To talk with ADFS we must be able to speak WS-Trust protocol, on the .NET platform this is a very easy thing to do thanks to WCF and Windows Identity Foundation frameworks, but regardless the platform make a WS-Trust call is not so hard.

The first thing that we need to know is that WS-Trust protocol defines an standard way of requesting security tokens, based on an XML structure known as Request Security Token or RST, this is an example of that structure:

<trust:RequestSecurityToken xmlns:trust="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
  <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
    <a:EndpointReference>
      <a:Address>https://yourcompany.com</a:Address>
    </a:EndpointReference>
  </wsp:AppliesTo>
  <trust:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Bearer</trust:KeyType>
  <trust:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</trust:RequestType>
  <trust:TokenType>urn:oasis:names:tc:SAML:2.0:assertion</trust:TokenType>
</trust:RequestSecurityToken>

Focusing on the basics, there is a couple of fields that are important to us, inside of the RequestSecurityToken element you will find the AppliesTo tag where, using the WS-Addressing standard, we define the scope to which the token is valid, in this case: https://yourcompany.com.

RequestType specifies the action that you want to execute, in our case “Issue”, this means that we want that the (Security Token Service) STS issue a new token, but another option could be renewed an already issued token, in that case the RequestType would be “Renew”.

Finally, the TokenType specifies the type of the token that you want, in our case we are asking for a token based on the SAML 2.0 format.

Doesn’t looks very hard, isn’t? but where do we say who we are? well, one detail that adds a bit of complexity is the fact that all the WS-* protocols stack is build on top of SOAP, so we need to speak SOAP in order to send the token request. Once more, speak SOAP is not so hard, SOAP is also XML-Based, I’m not going to explain the whole SOAP protocol, but you can find the format for a soap message here: http://www.w3.org/2003/05/soap-envelope/

In our case, to talk with ADFS from a native client we going to use username and password security, so this is how the SOAP message will looks like: (I’ve cut some arguments to improve the presentation)

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
            xmlns:a="http://www.w3.org/2005/08/addressing"
            xmlns:u="...">
  <s:Header>
    <a:Action s:mustUnderstand="1">

http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue

    </a:Action>
    <a:To s:mustUnderstand="1">https://yourcompany.com/adfs/services/trust/13/UsernameMixed</a:To>
    <o:Security s:mustUnderstand="1" mlns:o="...">
      <o:UsernameToken u:Id="uuid-6a13a244-dac6-42c1-84c5-cbb345b0c4c4-1">
        <o:Username>Leandro Boffi</o:Username>
        <o:Password Type="...">P@ssw0rd!</o:Password>
      </o:UsernameToken>
    </o:Security>
  </s:Header>
  <s:Body>
    <trust:RequestSecurityToken xmlns:trust="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
      <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
        <a:EndpointReference>
          <a:Address>https://yourcompany.com</a:Address>
        </a:EndpointReference>
      </wsp:AppliesTo>
      <trust:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Bearer</trust:KeyType>
      <trust:RequestType>

http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue

      </trust:Requesthttps://yourcompany.com/adfs/services/trust/13/UsernameMixedType>
      <trust:TokenType>urn:oasis:names:tc:SAML:2.0:assertion</trust:TokenType>
    </trust:RequestSecurityToken>
  </s:Body>
</s:Envelope>

To quickly understand the format, the SOAP envelop has two main tags: header and body. The body of our message contains the RST (Request for Security Token) message that we created before. In the header we can find context parameters like, the Uri of the service endpoint (To), the name of the action exposed in that endpoint that you want to execute (Action), remember that in SOAP you can have multiple actions in a single endpoint, and who we are (Security), in this case username and password.

To use UserName and Password authentication we need to look for the action Issue in the endpoint https://yourcompany.com/adfs/services/trust/13/UsernameMixed, so make sure that this endpoint is enabled on ADFS configuration.

Once we have the SOAP message, we just need to send it to the server using a regular HTTP POST, this is an example of how to do it on .NET, but it can be applied to any platform or language:

var client = new WebClient();

client.Headers.Add("Content-Type", "application/soap+xml; charset=utf-8");

var result = client.UploadString(
        address: "https://yourcompany.com/adfs/services/trust/13/UsernameMixed",
        method: "POST",
        data: soapMessage);

Make sure that you specify the Content-Type header to “application/soap+xml; charset=utf-8”, what you finally need to send to the server is this:

POST /adfs/services/trust/13/UsernameMixed HTTP/1.1

Connection: Keep-Alive

Content-Length: 1862

Content-Type: application/soap+xml; charset=utf-8

Accept-Encoding: gzip, deflate

Expect: 100-continue

Host: localhost

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">….</s:Envelope>

I’ve added other headers to be consistent with the HTTP Protocol, but for ADFS just the Content-Type is required.

The Answer: Request Security Token Response

If your credentials were valid, and the scope Uri is the right one, you will get a SOAP response from ADFS. In the body of that message you will get something like this:

<trust:RequestSecurityTokenResponseCollection xmlns:trust="...">
  <trust:RequestSecurityTokenResponse>
    <trust:Lifetime>...</trust:Lifetime>
    <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">...</wsp:AppliesTo>
    <trust:RequestedSecurityToken>
      <Assertion ID="_fcf06a39-c495-4074-8f22-4a7df6e26513"
                 IssueInstant="2012-02-21T04:27:24.771Z"
                 Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
        <Issuer>http://yourcompany.com/adfs/services/trust</Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
          <ds:SignedInfo>
            <ds:CanonicalizationMethod
              Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod
              Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#_fcf06a39-c495-4074-8f22-4a7df6e26513">
              <ds:Transforms>
                <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
              </ds:Transforms>
              <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
              <ds:DigestValue>...</ds:DigestValue>
            </ds:Reference>
          </ds:SignedInfo>
          <ds:SignatureValue>...</ds:SignatureValue>
          <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
            <ds:X509Data>
              <ds:X509Certificate>...</ds:X509Certificate>
            </ds:X509Data>
          </KeyInfo>
        </ds:Signature>
        <Subject>
          <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
            <SubjectConfirmationData NotOnOrAfter="2012-02-21T04:32:24.771Z"/>
          </SubjectConfirmation>
        </Subject>
        <Conditions NotBefore="2012-02-21T04:27:24.756Z" NotOnOrAfter="2012-02-21T05:27:24.756Z">
          <AudienceRestriction>
            <Audience>https://yourcompany.com/</Audience>
          </AudienceRestriction>
        </Conditions>
        <AttributeStatement>
          <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">
            <AttributeValue>Leandro Boffi</AttributeValue>
          </Attribute>
          <Attribute Name="http://schemas.microsoft.com/ws/2008/06/identity/claims/role">
            <AttributeValue>Administrator</AttributeValue>
            <AttributeValue>Mobile User</AttributeValue>
          </Attribute>
        </AttributeStatement>
        <AuthnStatement AuthnInstant="2012-02-21T04:27:24.724Z">
          <AuthnContext>
            <AuthnContextClassRef>
              urn:oasis:names:tc:SAML:2.0:ac:classes:Password
            </AuthnContextClassRef>
          </AuthnContext>
        </AuthnStatement>
      </Assertion>
    </trust:RequestedSecurityToken>
    <trust:RequestedAttachedReference>...</trust:RequestedAttachedReference>
    <trust:RequestedUnattachedReference>...</trust:RequestedUnattachedReference>
    <trust:TokenType>urn:oasis:names:tc:SAML:2.0:assertion</trust:TokenType>
    <trust:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</trust:RequestType>
    <trust:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Bearer</trust:KeyType>
  </trust:RequestSecurityTokenResponse>
</trust:RequestSecurityTokenResponseCollection>

This format is also specified in the WS-Trust protocol as “Request Security Token Response” or RSTR, but for you the most important section of the response is in:

RequestSecurityToeknResponseCollection/RequestSecurityToeknResponse/RequestedSecurityToken

The content of that tag is the security token, in our case a SAML 2.0 token:

<Assertion ID="_fcf06a39-c495-4074-8f22-4a7df6e26513" IssueInstant="2012-02-21T04:27:24.771Z"
                 Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
  <Issuer>http://yourcompany.com/adfs/services/trust</Issuer>
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:SignedInfo>
      <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
      <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
      <ds:Reference URI="#_fcf06a39-c495-4074-8f22-4a7df6e26513">
        <ds:Transforms>
          <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
          <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
        </ds:Transforms>
        <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
        <ds:DigestValue>...</ds:DigestValue>
      </ds:Reference>
    </ds:SignedInfo>
    <ds:SignatureValue>...</ds:SignatureValue>
    <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
      <ds:X509Data>
        <ds:X509Certificate>...</ds:X509Certificate>
      </ds:X509Data>
    </KeyInfo>
  </ds:Signature>
  <Subject>
    <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
      <SubjectConfirmationData NotOnOrAfter="2012-02-21T04:32:24.771Z"/>
    </SubjectConfirmation>
  </Subject>
  <Conditions NotBefore="2012-02-21T04:27:24.756Z" NotOnOrAfter="2012-02-21T05:27:24.756Z">
    <AudienceRestriction>
      <Audience>https://yourcompany.com/</Audience>
    </AudienceRestriction>
  </Conditions>
  <AttributeStatement>
    <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">
      <AttributeValue>Leandro Boffi</AttributeValue>
    </Attribute>
    <Attribute Name="http://schemas.microsoft.com/ws/2008/06/identity/claims/role">
      <AttributeValue>Administrator</AttributeValue>
      <AttributeValue>Mobile User</AttributeValue>
    </Attribute>
  </AttributeStatement>
  <AuthnStatement AuthnInstant="2012-02-21T04:27:24.724Z">
    <AuthnContext>
      <AuthnContextClassRef>
        urn:oasis:names:tc:SAML:2.0:ac:classes:Password
      </AuthnContextClassRef>
    </AuthnContext>
  </AuthnStatement>
</Assertion>

Once we extract the token from the response, everything gets simpler: Inside of the AttributeStatment section you will have a list of Attribute, this are the claims, information of the user, for example in this token we have three different claims:

• Type: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
• Value: Leandro Boffi

• Type: http://schemas.microsoft.com/ws/2008/06/identity/claims/role
• Value: Administrator

• Type: http://schemas.microsoft.com/ws/2008/06/identity/claims/role
• Value: Mobile User

You can use those claims to perform authorization in your application, but also if your app needs to call webservices that rely on your ADFS, you will need to send the entire token in each request that you made to those services (I’ll explain this scenario in a future post).

Security Features

The token has some security features with which we can get us to make our application more secure. I’m not going to explain all the features in this post, but for example, if we want we can verify that no body has modified the token, because it is signed by the issuer (in our case, ADFS). You can find the signature on Assertion/Signature/SignatureValue. This signature is also based on a standard called XML Signature, you can find the specification here: http://www.w3.org/Signature/.

Also another very important feature is the fact that the token has a limited life time, to avoid that somebody use an old token, you can find that in the Assertion/Conditions/NotBefore and NotOnOrAfter.

Conclusion

Integrate the identity of our apps to Active Directory, no matter the platform or the language is possible due to ADFS is based on WS-Trust an standard protocol. If your language do not support WS-Trust natively it requires a bit more of effort, but as we saw in this post it’s not hard at all, you just need an XML template for the SOAP+RST call and an HTTP Post.

Download here the template for doing the SOAP-RST call, just replace the values in brackets with your values and start requesting tokens!

Hope has been useful!

As you probably know, when you use claim-based identity in a project using WIF you have access to the user claims in the System.Thread.CurrentPrincipal.Identity property, but there is an small problem, it’s type is System.Security.IIdentity and to access to the claims you need to cast that property to Microsoft.IdentityModel.Claims.IClaimsIdentity so you end up with something like this in the middle of your app:

((IClaimsIdentity)Thread.CurrentPrincipal.Identity).Claims

That’s not sexy at all, and it gets worse if you need an specific claim, for example the email address of the user:

var user = ((IClaimsIdentity)Thread.CurrentPrincipal.Identity);
            
var email = user.Claims.FirstOrDefault(x => 
    x.ClaimType.Equals(ClaimTypes.Email, StringComparison.OrdinalIgnoreCase))
    .Value;

You can solve this with a simple extension method something like GetClaimValue(string claimType), and you’ll get something like this, but is still not sexy:

var user = ((IClaimsIdentity)Thread.CurrentPrincipal.Identity); 
                
var email = user.GetClaimValue(ClaimTypes.Email);

Wouldn’t it be better to have something like this?

var email = user.Email;

Yes, you guessed, using C# 4.0 dynamics and a little of reflection, that’s possible, we simply need to create a class called DynamicIdentity that extends the DynamicObject class, and find in the ClaimTypes (or in any class we want) the value for the type requested using the property name to search. For example, if we write user.Email we are asking for all the  claims defined  with the claim type ClaimTypes.Email (“http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress”).

This is how the DynamicIndentity class looks like:

public class DynamicIdentity : DynamicObject
{
    private ClaimTypeResolver claimTypeResolver;
    private IEnumerable<Claim> claims;

    public DynamicIdentity(IEnumerable<Claim> claims, ClaimTypeResolver typeResolver)
    {
        this.claims = claims;
        this.claimTypeResolver = typeResolver;
    }

    public override bool TryGetMember(GetMemberBinder binder, out object result)
    {
        var claimType = this.claimTypeResolver.Resolve(binder.Name);
        
        var claims = this.claims.Where(x => 
            x.ClaimType.Equals(claimType, StringComparison.OrdinalIgnoreCase));

        if (claims.Count() == 0)
        {
            throw new ArgumentException(
                string.Format("Claim with type '{0}' was not found", claimType));
        }

        if (claims.Count() == 1)
        {
            result = claims.First().Value;
            return true;
        }

        result = claims.Select(x => x.Value).ToArray();
        return true;
    }
}

The ClaimTypeResolver class is responsible for resolving the Claim Type value based on the property name:

public class ClaimTypeResolver
{
    private Type[] typesDefinition;

    public ClaimTypeResolver(Type[] typesDefinition)
    {
        this.typesDefinition = typesDefinition;
    }

    public string Resolve(string friendlyName)
    {
        foreach (var type in this.typesDefinition)
        {
            var field = type.GetField(friendlyName);

            if (field != null)
            {
                return field.GetRawConstantValue().ToString();
            }
        }

        throw new ArgumentException(
            string.Format("Claim Type '{0}' was not found.", friendlyName));
    }
}

Notice that it receives an array with the types that contains the constants for your claim types.

Once we have that, we just need to create and extension method of the IPrincipal class that returns this dynamic object:

public static dynamic AsDynamic(this IPrincipal user)
{
    var claims = ((IClaimsIdentity)user.Identity).Claims.AsEnumerable();

    var resolver = new ClaimTypeResolver(new Type[] 
    { 
        typeof(ClaimTypes),
        typeof(MyCompanyClaimTypes),
    });

    return new DynamicIdentity(claims, resolver);
}

That’s all, this is the final experience for the developer:

var user = Thread.CurrentPrincipal.AsDynamic();

Console.WriteLine("Email: {0}", user.Email);

foreach (var role in user.Role)
{
    Console.WriteLine("Role: {0}", role);
}

Download the code here!

Today the P&P Team has released the Enterprise Library Integration Pack for Windows Azure. I’ve been collaborating with the team as advisor and It was a very enriching experience.

Among others, the release includes:

Two news application blocks:

• Autoscaling Application Block (code name "Wasabi") to help you to automatically scale both web and worker roles in Windows Azure by dynamically provisioning/decommissioning roles or throttling. These scaling actions are based on timetables or on metrics collected from the application and/or Windows Azure Diagnostics.

• Transient Fault Handling Application Block (code name "Topaz") to help you make your Windows Azure application more resilient to transient errors when you are using these cloud services: SQL Azure, Windows Azure Storage, Windows Azure Caching, and Windows Azure Service Bus.

One new configuration source:

• Blob configuration source to load configuration information from a blob in your Azure Storage account so that you can modify it without having to redeploy your application to Windows Azure.

The release is published as a nuget package here.

Enjoy it!!

The WSTrustClient class has been replaced for the WSTrustChannelFactory class, in order to continue with the WCF programming model with Channels. So, said that, this is the code you need to get a token from ADFS:

var stsEndpoint = "https://[server]/adfs/services/trust/13/windowstransport";
var relayPartyUri = "https://localhost:8080/WebApp";

var factory = new WSTrustChannelFactory(
    new WindowsWSTrustBinding(SecurityMode.Transport), 
    new EndpointAddress(stsEndpoint));

factory.TrustVersion = TrustVersion.WSTrust13;

var rst = new RequestSecurityToken
{
    RequestType = RequestTypes.Issue,
    AppliesTo = new EndpointAddress(relayPartyUri),
    KeyType = KeyTypes.Symmetric
};

var channel = factory.CreateChannel();
            
SecurityToken token = channel.Issue(rst);

Note that in the example I’m using the Windows Transport endpoint, and that’s why I’m using SecurityMode.Transport when I create the binding.

This part is focused on application integration, it shows how to integrate your applications running on premise with  your cloud applications running on azure, showing features like Service Bus, AppFabric Cache, Traffic Manager, etc.

You can download the last drop in the Windows Azure Guideline site: http://wag.codeplex.com/