Service Bus Authentication and Authorization

Applications can authenticate to Microsoft Azure Service Bus using either Shared Access Signature (SAS) authentication, or by authenticating through the Microsoft Azure Active Directory Access Control (also known as Access Control Service or ACS).

Shared Access Signature authentication enables applications to authenticate to Service Bus using an access key configured on the namespace, or on the entity with which specific rights are associated. You can then use this key to generate a Shared Access Signature token that clients can use to authenticate to Service Bus.
ACS provides federation with various standards-based identity providers. ACS federates with enterprise directories such as Active Directory Federation Services (ADFS) and web identities. These identities include Microsoft accounts (Windows Live IDs), Google, Yahoo!, and Facebook.

SAS provides a simple, flexible, and easy-to-use authentication scheme for Service Bus. Applications can use SAS in scenarios in which they do not need to manage the notion of an authorized “user.”

Applications that require a rich, identity-based authentication can use ACS for authenticating to Service Bus.

What Is a Shared Access Signature?

A shared access signature provides delegated access to resources in your storage account. This means that you can grant a client limited permissions to your blobs, queues, or tables for a specified period of time and with a specified set of permissions, without having to share your account access keys. The SAS is a URI that encompasses in its query parameters all of the information necessary for authenticated access to a storage resource. To access storage resources with the SAS, the client only needs to pass in the SAS to the appropriate constructor or method.

When Should You Use a Shared Access Signature?

You can use a SAS when you want to provide access to resources in your storage account to a client that can't be trusted with the account key. Your storage account keys include both a primary and secondary key, both of which grant administrative access to your account and all of the resources in it. Exposing either of your account keys opens your account to the possibility of malicious or negligent use. Shared access signatures provide a safe alternative that allows other clients to read, write, and delete data in your storage account according to the permissions you've granted, and without need for the account key.

A common scenario where a SAS is useful is a service where users read and write their own data to your storage account. In a scenario where a storage account stores user data, there are two typical design patterns:

1. Clients upload and download data via a front-end proxy service, which performs authentication. This front-end proxy service has the advantage of allowing validation of business rules, but for large amounts of data or high-volume transactions, creating a service that can scale to match demand may be expensive or difficult.

2. A lightweight service authenticates the client as needed and then generates a SAS. Once the client receives the SAS, they can access storage account resources directly with the permissions defined by the SAS and for the interval allowed by the SAS. The SAS mitigates the need for routing all data through the front-end proxy service.

Many real-world services may use a hybrid of these two approaches, depending on the scenario involved, with some data processed and validated via the front-end proxy while other data is saved and/or read directly using SAS.

How a Shared Access Signature Works

A shared access signature is a URI that points to a storage resource and includes a special set of query parameters that indicate how the resource may be accessed by the client. One of these parameters, the signature, is constructed from the SAS parameters and signed with the account key. This signature is used by Azure Storage to authenticate the SAS.

A shared access signature has the following constraints that define it, each of which is represented as a parameter on the URI:

The storage resource. Storage resources for which you can delegate access include containers, blobs, queues, tables, and ranges of table entities.
Start time. This is the time at which the SAS becomes valid. The start time for a shared access signature is optional; if omitted, the SAS is effective immediately.
Expiry time. This is the time after which the SAS is no longer valid. Best practices recommend that you either specify an expiry time for a SAS, or associate it with a stored access policy (see more below).
Permissions. The permissions specified on the SAS indicate what operations the client can perform against the storage resource using the SAS.

Here is an example of a SAS URI that provides read and write permissions to a blob. The table breaks down each part of the URI to understand how it contributes to the SAS:

https://myaccount.blob.core.windows.net/sascontainer/sasblob.txt?sv=2012-02-12&st=2013-04-29T22%3A18%3A26Z&se=2013-04-30T02%3A23%3A26Z&sr=b&sp=rw&sig=Z%2FRHIX5Xcg0Mq2rqI3OlWTjEg2tYkboXr1P9ZUXDtkk%3D

Blob URI	https://myaccount.blob.core.windows.net/sascontainer/sasblob.txt	The address of the blob. Note that using HTTPS is highly recommended.
Storage services version	sv=2012-02-12	For storage services version 2012-02-12 and later, this parameter indicates the version to use.
Start time	st=2013-04-29T22%3A18%3A26Z	Specified in an ISO 8061 format. If you want the SAS to be valid immediately, omit the start time.
Expiry time	se=2013-04-30T02%3A23%3A26Z	Specified in an ISO 8061 format.
Resource	sr=b	The resource is a blob.
Permissions	sp=rw	The permissions granted by the SAS include Read (r) and Write (w).
Signature	sig=Z%2FRHIX5Xcg0Mq2rqI3OlWTjEg2tYkboXr1P9ZUXDtkk%3D	Used to authenticate access to the blob. The signature is an HMAC computed over a string-to-sign and key using the SHA256 algorithm, and then encoded using Base64 encoding.

Controlling Shared Access Signatures with a Stored Access Policy

A shared access signature can take one of two forms:

Ad hoc SAS: When you create an ad hoc SAS, the start time, expiry time, and permissions for the SAS are all specified on the SAS URI (or implied, in the case where start time is omitted). This type of SAS may be created on a container, blob, table, or queue.
SAS with stored access policy: A stored access policy is defined on a resource container - a blob container, table, or queue - and can be used to manage constraints for one or more shared access signatures. When you associate a SAS with a stored access policy, the SAS inherits the constraints - the start time, expiry time, and permissions - defined for the stored access policy.

The difference between the two forms is important for one key scenario: revocation. A SAS is a URL, so anyone who obtains the SAS can use it, regardless of who requested it to begin with. If a SAS is published publically, it can be used by anyone in the world. A SAS that is distributed is valid until one of four things happens:

The expiry time specified on the SAS is reached.
The expiry time specified on the stored access policy referenced by the SAS is reached (if a stored access policy is referenced, and if it specifies an expiry time). This can either occur because the interval elapses, or because you have modified the stored access policy to have an expiry time in the past, which is one way to revoke the SAS.
The stored access policy referenced by the SAS is deleted, which is another way to revoke the SAS. Note that if you recreate the stored access policy with exactly the same name, all existing SAS tokens will again be valid according to the permissions associated with that stored access policy (assuming that the expiry time on the SAS has not passed). If you are intending to revoke the SAS, be sure to use a different name if you recreate the access policy with an expiry time in the future.
The account key that was used to create the SAS is regenerated. Note that doing this will cause all application components using that account key to fail to authenticate until they are updated to use either the other valid account key or the newly regenerated account key.

Best Practices for Using Shared Access Signatures

When you use shared access signatures in your applications, you need to be aware of two potential risks:

If a SAS is leaked, it can be used by anyone who obtains it, which can potentially compromise your storage account.
If a SAS provided to a client application expires and the application is unable to retrieve a new SAS from your service, then the application's functionality may be hindered.

The following recommendations for using shared access signatures will help balance these risks:

Always use HTTPS to create a SAS or to distribute a SAS. If a SAS is passed over HTTP and intercepted, an attacker performing a man-in-the-middle attack will be able to read the SAS and then use it just as the intended user could have, potentially compromising sensitive data or allowing for data corruption by the malicious user.
Reference stored access policies where possible. Stored access policies give you the option to revoke permissions without having to regenerate the storage account keys. Set the expiration on these to be a very long time (or infinite) and make sure that it is regularly updated to move it farther into the future.
Use near-term expiration times on an ad hoc SAS. In this way, even if a SAS is compromised unknowingly, it will only be viable for a short time duration. This practice is especially important if you cannot reference a stored access policy. This practice also helps limit the amount of data that can be written to a blob by limiting the time available to upload to it.
Have clients automatically renew the SAS if necessary. Clients should renew the SAS well before the expected expiration, in order to allow time for retries if the service providing the SAS is unavailable. If your SAS is meant to be used for a small number of immediate, short-lived operations, which are expected to be completed within the expiration time given, then this may not be necessary, as the SAS is not expected be renewed. However, if you have client that is routinely making requests via SAS, then the possibility of expiration comes into play. The key consideration is to balance the need for the SAS to be short-lived (as stated above) with the need to ensure that the client is requesting renewal early enough to avoid disruption due to the SAS expiring prior to successful renewal.
Be careful with SAS start time. If you set the start time for a SAS to now, then due to clock skew (differences in current time according to different machines), failures may be observed intermittently for the first few minutes. In general, set the start time to be at least 15 minutes ago, or don't set it at all, which will make it valid immediately in all cases. The same generally applies to expiry time as well - remember that you may observe up to 15 minutes of clock skew in either direction on any request. Note for clients using a REST version prior to 2012-02-12, the maximum duration for a SAS that does not reference a stored access policy is 1 hour, and any policies specifying longer term than that will fail.
Be specific with the resource to be accessed. A typical security best practice is to provide a user with the minimum required privileges. If a user only needs read access to a single entity, then grant them read access to that single entity, and not read/write/delete access to all entities. This also helps mitigate the threat of the SAS being compromised, as the SAS has less power in the hands of an attacker.
Understand that your account will be billed for any usage, including that done with SAS. If you provide write access to a blob, a user may choose to upload a 200GB blob. If you've given them read access as well, they may choose do download it 10 times, incurring 2TB in egress costs for you. Again, provide limited permissions, to help mitigate the potential of malicious users. Use short-lived SAS to reduce this threat (but be mindful of clock skew on the end time).
Validate data written using SAS. When a client application writes data to your storage account, keep in mind that there can be problems with that data. If your application requires that that data be validated or authorized before it is ready to use, you should perform this validation after the data is written and before it is used by your application. This practice also protects against corrupt or malicious data being written to your account, either by a user who properly acquired the SAS, or by a user exploiting a leaked SAS.
Don't always use SAS. Sometimes the risks associated with a particular operation against your storage account outweigh the benefits of SAS. For such operations, create a middle-tier service that writes to your storage account after performing business rule validation, authentication, and auditing. Also, sometimes it's simpler to manage access in other ways. For example, if you want to make all blobs in a container publically readable, you can make the container Public, rather than providing a SAS to every client for access.
Use Storage Analytics to monitor your application. You can use logging and metrics to observe any spike in authentication failures due to an outage in your SAS provider service or or to the inadvertent removal of a stored access policy. See the Azure Storage Team Blog for additional information.

Note :-

Shared access signatures are useful for providing limited permissions to your storage account to clients that should not have the account key. As such, they are a vital part of the security model for any application using Azure Storage. If you follow the best practices listed here, you can use SAS to provide greater flexibility of access to resources in your storage account, without compromising the security of your application.

What is ACS?

Most developers are not identity experts and do not want to spend time developing authentication and authorization mechanisms for their applications and services. ACS is an Azure service that provides an easy way for you to authenticate users to access your web applications and services without having to add complex authentication logic to your code.

The following features are available in ACS:

Integration with Windows Identity Foundation (WIF).
Support for popular web identity providers (IPs) including Microsoft accounts (formerly known as Windows Live ID), Google, Yahoo, and Facebook.
Support for Active Directory Federation Services (AD FS) 2.0.
An Open Data Protocol (OData)-based management service that provides programmatic access to ACS settings.
A Management Portal that allows administrative access to the ACS settings.

For more information about ACS, see Access Control Service 2.0.

Concepts

ACS is built on the principles of claims-based identity -- a consistent approach to creating authentication mechanisms for applications running on-premises or in the cloud. Claims-based identity provides a common way for applications and services to get the identity information they need about users inside their organization, in other organizations, and on the Internet.

To complete the tasks in this guide, you should understand the following terms and concepts are used in this guide:

Client - A browser that is attempting to gain access to your web application.

Relying party (RP) application - Your web app. An RP application is a website or service that outsources authentication to one external authority. In identity jargon, we say that the RP trusts that authority. This guide explains how to configure your application to trust ACS.

Token - A user gains access to an RP application by presenting a valid token that was issued by an authority that the RP application trusts. A collection of security data that is issued when a client is authenticated. It contains a set of claims, which are attributes of the authenticated user, such as a user's name or age, or an identifier for a user role. A token is digitally signed so its issuer can be identified and its content cannot be changed.

Identity Provider (IP) - An authority that authenticates user identities and issues security tokens, such as Microsoft account (Windows Live ID), Facebook, Google, Twitter, and Active Directory. When ACS is configured to trust an IP, it accepts and validates the tokens that the IP issues. Because ACS can trust multiple IPs at the same time, when your application trusts ACS, you can your application can offer users the option to be authenticated by any of the IPs that ACS trusts on your behalf.

Federation Provider (FP) - Identity providers (IPs) have direct knowledge of users, authenticate users by using their credentials, and issue claims about users. A Federation Provider (FP) is a different kind of authority. Instead of authenticating users directly, the FP brokers authentication. It acts as an intermediary between a relying party application and one or more IPs. ACS is a federation provider (FP).

ACS Rule Engine - Claims transformation rules convert the claims in tokens from trusted IPs so they can be used by an RP. ACS includes a rule engine that applies the claims transformation rules that you specify for your RP.

Access Control Namespace - Provides a unique scope for addressing ACS resources within your application. The namespace contains your settings, such as the IPs you trust, the RP applications you want to serve, the rules that you apply to incoming tokens, and it displays the endpoints that the application and the developer use to communicate with ACS.

The following figure shows how ACS authentication works with a web application:

The client (in this case, a browser) requests a page from the RP.
Since the request is not yet authenticated, the RP redirects the user to the authority that it trusts, which is ACS. The ACS presents the user with the choice of IPs that were specified for this RP. The user selects the appropriate IP.
The client browses to the IP's authentication page, and prompts the user to log on.
After the client is authenticated (for example, the identity credentials are entered), the IP issues a security token.
After issuing a security token, the IP directs the client to send the security token that the IP issued to ACS.
ACS validates the security token issued by the IP, inputs the identity claims in this token into the ACS rules engine, calculates the output identity claims, and issues a new security token that contains these output claims.
ACS directs the client to send the security token that ACS issued to the RP. The RP validates the signature on the security token, extracts claims for use by the application business logic, and returns the page that was originally requested.

Prerequisites

To complete the tasks in this guide, you will need the following:

Azure subscription
Microsoft Visual Studio 2012
Identity and Access Tool for Visual Studio 2012 (To download, see Identity and Access Tool)

Create an Access Control Namespace

To use Active Directory Access Control in Azure, create an Access Control namespace. The namespace provides a unique scope for addressing ACS resources within your application.

Log into the Azure Management Portal (https://manage.WindowsAzure.com).
Click Active Directory.
To create a new Access Control namespace, click New. App Services and Access Control will be selected. Click Quick Create.
Enter a name for the namespace. Azure verifies that the name is unique.
Select the region in which the namespace is used. For best performance, use the region in which you are deploying your application, and then clickCreate.

Azure creates and activates the namespace.

Create an ASP.NET MVC Application

In this step, you create a ASP.NET MVC application. In later steps, we'll integrate this simple web forms application with ACS.

Start Visual Studio 2012 or Visual Studio Express for Web 2012 (Previous versions of Visual Studio will not work with this tutorial).
Click File, and then click New Project.
Select the Visual C#/Web template, and then select ASP.NET MVC 4 Web Application.

We'll use a MVC application for this guide, but you can use any web application type for this task.
In Name, type MvcACS, and then click OK.
In the next dialog, select Internet Application, and then click OK.

Edit the Views\Shared_LoginPartial.cshtml file and replace the contents with the following code:

@if (Request.IsAuthenticated)
{
    string name = "Null ID";
    if (!String.IsNullOrEmpty(User.Identity.Name))
    {
        name = User.Identity.Name;
    }    
    <text>
    Hello, @Html.ActionLink(name, "Manage", "Account", routeValues: null, htmlAttributes: new { @class = "username", title = "Manage" })!
            @using (Html.BeginForm("LogOff", "Account", FormMethod.Post, new { id = "logoutForm" }))
            {
                @Html.AntiForgeryToken()
                <a href="javascript:document.getElementById('logoutForm').submit()">Log off</a>
            }
    </text>
}
else
{
    <ul>
        <li>@Html.ActionLink("Register", "Register", "Account", routeValues: null, htmlAttributes: new { id = "registerLink" })</li>
        <li>@Html.ActionLink("Log in", "Login", "Account", routeValues: null, htmlAttributes: new { id = "loginLink" })</li>
    </ul>
}

Currently, ACS doesn't set User.Identity.Name, so we need to make the above change.

Press F5 to run the application. The default ASP.NET MVC application appears in your web browser.

Integrate your Web Application with ACS

In this task, you will integrate your ASP.NET web application with ACS.

In Solution Explorer, right-click the MvcACS project, and then select Identity and Access.

If the Identity and Access option does not appear on the context menu, install the Identity and Access Tool. For information, see Identity and Access Tool.
On the Providers tab, select Use the Azure Access Control Service.
Click the Configure link.

Visual Studio requests information about the Access Control namespace. Enter the namespace name you created earlier (Test in this images above, but you will have a different namespace). Switch back to the Azure Management Portal to get the symmetric key.
In the Azure Management Portal, click the Access Control namespace and then click Manage.
Click Management Service and then click Management Client.
Click Symmetric Key, click Show Key, and copy the key value. Then, click Cancel to exit the Edit Management Client page without making changes.
In Visual Studio, paste the key in the Enter the Management Key for the namespace field and click Save management key, and then click OK.

Visual Studio uses the information about the namespace to connect to the ACS Management Portal and get the settings for your namespace, including the identity providers, realm, and return URL.
Select Windows Live ID (Microsoft account) and click OK.

Test the Integration with ACS

This task explains how to test the integration of your RP application and ACS.

Press F5 in Visual Studio to run the app.

When your application is integrated with ACS and you have selected Windows Live ID (Microsoft account), instead of opening the default ASP.NET Web Forms application, your browser is redirected to the sign-in page for Microsoft accounts. When you sign in with a valid user name a password, you are then redirected to the MvcACS application.

Congratulations! You have successfully integrated ACS with your ASP.NET web application. ACS is now handling the authentication of users using their Microsoft account credentials.

View Claims Sent By ACS

In this section we will modify the application to view the claims sent by ACS. The Identity and Access tool has created a rule group that passes through all claims from the IP to your application. Note that different identity providers send different claims.

Open the Controllers\HomeController.cs file. Add a using statement for System.Threading:

using System.Threading;
In the HomeController class add the Claims method:

public ActionResult Claims() { ViewBag.Message = "Your claims page.";
```
ViewBag.ClaimsIdentity = Thread.CurrentPrincipal.Identity;

return View();
```
}
Right click on the Claims method and select Add View.

Click Add.

Replace the contents of the Views\Home\Claims.cshtml file with the following code:

@{
    ViewBag.Title = "Claims";
}
<hgroup class="title">
    <h1>@ViewBag.Title.</h1>
    <h2>@ViewBag.Message</h2>
</hgroup>
<h3>Values from Identity</h3>
<table>
    <tr>
        <td>
            IsAuthenticated: 
        </td>
        <td>
            @ViewBag.ClaimsIdentity.IsAuthenticated 
        </td>
    </tr>
    <tr>
        <td>
            Name: 
        </td>        
        <td>
            @ViewBag.ClaimsIdentity.Name
        </td>        
    </tr>
</table>
<h3>Claims from ClaimsIdentity</h3>
<table>
    <tr>
        <th>
            Claim Type
        </th>
        <th>
            Claim Value
        </th>
    </tr>
        @foreach (System.Security.Claims.Claim claim in ViewBag.ClaimsIdentity.Claims ) {
    <tr>
        <td>
            @claim.Type
        </td>
        <td>
            @claim.Value
        </td>
    </tr>
}
</table>

Run the application and navigate to the Claims method:

For more information on using claims in your application, see the Windows Identity Foundation library.

View the App in the ACS Management Portal

The Identity and Access Tool in Visual Studio automatically integrates your application with ACS.

When you select the Use Azure Access Control option and then run your application, the Identity and Access Tool adds your application as a relying party, configures it to use the selected identity providers, and generates and selects the default claims transformation rules for the application.

You can review and change these configuration settings in the ACS Management Portal. Use the following steps to review the changes in the portal.

Log into the Windows Azure Management Portal.
Click Active Directory.
Select an Access Control namespace and then click Manage. This action opens the ACS Management Portal.
Click Relying party applications.

The new MvcACS application appears in the list of relying party applications. The realm is automatically set to the application main page.
Click MvcACS.

The Edit Relying Party Application page contains configuration settings for the MvcACS web application. When you change the settings on this page and save them, the changes are immediately applied to the application.
Scroll down the page to see the remaining configuration settings for the MvcACS application, including the identity providers and claims transformation rules.

In the next section, we'll use the features of the ACS Management Portal to make a change to the web application -- just to show how easy it is to do.

Add an Identity Provider

Let's use the ACS Management Portal to change the authentication of our MvcACS application. In this example, we'll add Google as an identity provider for MvcACS.

Click Identity providers (in the navigation menu) and then click Add.
Click Google and then click Next. The MvcACS app checkbox is selected by default.
Click Save.

Done! If you go back to Visual Studio, open the project for the MvcACS app, and click Identity and Access, the tool lists both the Windows Live ID and Google identity providers.

And, when you run your application, you'll see the effect. When an application supports more than one identity provider, the user's browser is first directed to a page hosted by ACS that prompts the user to choose an identity provider.

After the user selects an identity provider, the browser goes to the identity provider sign-in page.

What's Next

You have created a web application that is integrated with ACS. But, this is just the beginning! You can expand on this scenario.

For example, you can add more identity providers for this RP or allow users registered in enterprise directories, such as Active Directory Domain Services, to log on to the web application.

You can also add rules to your namespace that determine which claims are sent to an application for processing in the application business logic.

To further explore ACS functionality and to experiment with more scenarios, see Access Control Service 2.0.

Dot Net Deewane

Search This Blog