Securing Your SharePoint and Windows Azure Solutions : Configuring Shared Access Permissions for BLOB Storage - Using Claims-Based Authentication

CBA, as the name implies, is all about providing a claim so that you can get access to a specific resource. Think of your position in your company and the different levels of access to information that role grants you. For example, if you’re a developer, you might not have access to the same profit and loss information that a president does—although you’ll both have access to a similar set of human resources data. In this sense, you could think of the different claims as “developer” and “president,” with each of these claims providing access to a different set of resources. Claims can obviously get more complex and are defined within what is called a SAML token (SAML stands for Security Assertion Markup Language), but in essence claims represent information about an application that is requesting access to a set of resources.

Within CBA, you’ll come across a very specific set of terms that describe the constituent parts of security architecture. For example, you will come across identity providers (IPs), which is the application that provides your identity (such as Yahoo or Windows Live for ACS); relying party (RP), which grants access to the resource; Security Token Service (STS), which is the service that builds, signs, and issues security tokens; and trust, which is what is required across the IP, RP, and STS. With these constituent parts, CBA allows you to create and manage claims across domains and issue security tokens that allow access to specific resources within a domain.

As you learned earlier in this chapter, ACS provides a layer of security for the services you deploy to the AppFabric service bus. However, it might not be realistic to give every application that wants to use your service access to the secret token and key you used in your client and service applications. You might require an additional level of security for your solution integration, one that is more flexible and comprehensive than just the ACS token and secret. CBA can provide this additional layer of protection. CBA does not always act alone, though. In many cases, you use related technologies such as WS-Trust or WS-Federation.

WS-Trust and WS-Federation provide a way to flow your security and authentication to other domains. WS-Federation provides a passive request/response pattern for managing security tokens from an STS through browser redirects. WS-Trust is active and represents a pattern used for security tokens used within rich client applications and web services.

WS-Federation is a way to manage identities across boundaries, and for the integration between Windows Azure and SharePoint, WS-Federation has some promise. WS-Federation essentially defines an integrated model for federating identity, authentication, and authorization across domains.

WS-Federation can be used with Active Directory Federation Services (AD FS) to provide federated single sign-on. AS FS 2.0 supports both WS-Federation and WS-Trust. A scenario in which WS-Federation works is when you host a web application in Windows Azure that is secured with ACS. Using WS-Federation, AD FS, and Windows Azure, you can configure AD FS as the identity provider and then federate that identity out to your Windows Azure application. The integration with SharePoint arrives in the form of an iframe integration with federated authentication and single sign-on access for the SharePoint user out to the hosted Windows Azure application.

WS-Trust provides a framework for managing trust between SOAP-based web services. It is a WS-* specification that is an OASIS standard; it provides extensions to WS-Security and supports issuing, renewing, and validating security tokens as well as brokering the trust relationship across service endpoints. By using WS-Trust, you can build integrated applications that securely communicate in a trusted way by using web services. Within WS-Trust, you will come across some specific concepts that help mediate this trust relationship. For example, you will use and apply the content of an STS. You will also find particular formats within the service messages that conform to security token requests, as well as responses and specific methods for the exchange of these messages. You implement WS-Trust within web services to combine your application or WCF service and Windows Identity Foundation (WIF) when building this additional security layer.

When using WS-Trust, you can create a claim programmatically and then extract the claim from the incoming service call. The claim can be stored as a URL or in the header or body of the service message using, for example, the ServiceAuthorizationManager class, which supports the authorization of service operations. For example, to extract information from the service header, you can use the WebOperationContext class shown here:

...
string authHeaderInfo = "";
authHeaderInfo = WebOperationContext.Current.IncomingRequest.Headers[HttpRequestHeader.
Authorization];
...

You can also use the RequestSecurityToken class, which represents a security token request. For example, the following code snippet shows how you can create a trusted channel with the service and then use the RequestSecurityToken to request the trusted token:

...
     static SecurityToken GetIssuedToken(string username, string password,
        string identityProviderEndpoint, string ACSEndpoint)
        {
            IssuedTokenWSTrustBinding ACSBinding = new IssuedTokenWSTrustBinding();
            WSTrustBindingBase identityProviderBinding = new
                UserNaeWSTrustBinding(SecurityMode.TransportWithMessageCredential);

            ACSBinding.SecurityMode = SecurityMode.TransportWithMessageCredential;
            ACSBinding.TrustVersion = TrustVersion.WSTrust13;

            ACSBinding.IssuerAddress = new EndpointAddress(identityProviderEndpoint);
            ACSBinding.IssuerBinding = identityProviderBinding;

            WSTrustChannelFactory trustChannelFactory = new WSTrustChannelFactory(
                ACSBinding,
                new EndpointAddress(ACSEndpoint)
                );
            trustChannelFactory.TrustVersion = TrustVersion.WSTrust13;
            trustChannelFactory.Credentials.UserName.UserName = username;
            trustChannelFactory.Credentials.UserName.Password = password;

            RequestSecurityToken rst = new RequestSecurityToken(
                WSTrust13Constants.RequestTypes.Issue);
            rst.KeyType = KeyTypes.Symmetric;
            rst.AppliesTo = new EndpointAddress(
                "http://localhost/claimsService/Service.svc");
            WSTrustChannel channel = (WSTrustChannel)trustChannelFactory.CreateChannel();
            RequestSecurityTokenResponse rstr;
            SecurityToken token = channel.Issue(rst, out rstr);
            channel.Close();
            trustChannelFactory.Close();
            return token;
        }
...

In the code snippet, you first create a new binding to the ACS token and then set some properties of the ACS token binding (ACSBinding). The token in this case is being federated from AD FS, and the UserName and Password properties map to string values that are retrieved from the user logon to the local client machine. When you have the token, you use the WSTrustChannelFactory class to create a trusted channel between your service endpoints.