Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
Windows Azure

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

11/28/2012 4:29:39 PM
Whenever you have created an application that interacts with Windows Azure, you created a claim of some sort, whether it is an X.509 certificate or the ACS token and key or a simple user name and password logon.

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.

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

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

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

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

            RequestSecurityToken rst = new RequestSecurityToken(
            rst.KeyType = KeyTypes.Symmetric;
            rst.AppliesTo = new EndpointAddress(
            WSTrustChannel channel = (WSTrustChannel)trustChannelFactory.CreateChannel();
            RequestSecurityTokenResponse rstr;
            SecurityToken token = channel.Issue(rst, out rstr);
            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.

Other -----------------
- Securing Your SharePoint and Windows Azure Solutions : Configuring Shared Access Permissions for BLOB Storage - Using Certificate-Based Authentication
- Securing Your SharePoint and Windows Azure Solutions : Configuring Shared Access Permissions for BLOB Storage - Using the Service Bus and Access Control Service
- Securing Your SharePoint and Windows Azure Solutions : Create a Windows Forms Application to Display the Shared Access Permissions Signature
- Securing Your SharePoint and Windows Azure Solutions : Configuring BCS Security - Create an Application ID, Assess Permissions on the ECT
- Deploying to Windows Azure : Changing live configuration, Upgrading the deployment, Running the deployment
- Deploying to Windows Azure : Preparation application for deployment, Ready for deployment
- Setting up hosted service in Windows Azure
- Azure Monitoring and Diagnostics : Logging config data in our application, Transferring and persisting diagnostic data
- Azure Monitoring and Diagnostics : Azure Diagnostics­ under the hood, Enabling diagnostic logging
- Web Services and Azure : Our WCF web services
Top 10 video Game
-   Renoir [PS4/XOne/PC] Kickstarter Trailer
-   Poly Bridge [PC] Early Access Trailer
-   Renoir [PS4/XOne/PC] Gameplay Explanation Trailer
-   Renoir [PS4/XOne/PC] More About Trailer
-   King's Quest: A Knight to Remember [PS3/PS4/X360/XOne/PC] Complete Collection Trailer
-   Samurai Warriors Chronicles 3 | Announcement Trailer
-   FIFA 16 | No Touch Dribbling with Lionel Messi
-   Why We're Cautiously Optimistic For The Final Fantasy VII Remake
-   Civilization: Beyond Earth – Rising Tide [PC] E3 Gameplay Walkthrough
-   Why We're Excited For the FFVII Remake
-   Mortal Kombat X | Predator Brutality
-   Mortal Kombat X | Predator Fatality
-   Poly Bridge [PC] Early Access Trailer
-   Silence: The Whispered World 2 [PS4/XOne/PC] Cinematic Trailer
-   Devilian [PC] Debut Trailer
Popular tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 windows Phone 7 windows Phone 8
programming4us programming4us
Popular keywords
HOW TO Swimlane in Visio Visio sort key Pen and Touch Creating groups in Windows Server Raid in Windows Server Exchange 2010 maintenance Exchange server mail enabled groups Debugging Tools Collaborating
programming4us programming4us
PS4 game trailer XBox One game trailer
WiiU game trailer 3ds game trailer
Trailer game
Heroes Charge
Windows Vista
Windows 7
Windows Azure
Windows Server
Game Trailer