Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Azure

Example: A return to our string-reversing service (part 4) - Configuring the ACS namespace

3/19/2011 11:53:48 AM
- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire

7. Configuring the ACS namespace

The ACS needs to be configured for your service. You’ve already learned how to define a namespace, and the namespace is a container for the rest of the ACS configuration. You can also chain namespaces together, which is the key mechanism for providing simple delegation.

Each namespace has four components: issuers, scopes, rules, and token policies. These elements work together to help secure your REST service.

The AppFabric SDK provides two tools for configuring your service, both of which run locally and call into the management service: ACM.exe (used from the command line) and the Azure configuration browser. (You can use the management service as a third option, but that’ll require more work on your part.) Beyond the tool that sets up the namespace, there aren’t any management tools on the ACS portal.

The ACM.exe tool can be found in the tools folder where you installed the AppFabric SDK. ACM is most useful when you’re automating a process or want to script the configuration. But keep in mind that calls to the AppFabric management endpoint aren’t free, like the Windows Azure management endpoints are.

The Azure configuration browser is shipped with the SDK, but as a sample in source-code form in a separate download file. You need to load the solution and compile it to use it. This distribution approach is really useful because you can then extend the tool to meet your needs, and the browser is a lot easier to use than the command-line tool.

The configuration browser does have a few limitations. First, it’s really ugly, but that’s OK. The second is that, at this time, it can’t update an existing cloud configuration; it can only deploy a complete configuration. This means that any time you make a change, you have to delete the configuration in the cloud and completely redeploy the new configuration. An advantage of this approach is that you can store your configuration locally in an XML file, which aids in backup and configuration management.

You’ll need to provide your service name and your management key with either tool. For the ACM.exe application, you can put your settings in the app.config file, which saves you from having to type them in as part of your commands every single time.

Issuers

Issuers are actors in the ACS system and represent consumers of your service. When you create an issuer, you need to provide both a display name and an official issuer name. Once the issuer is created, a signing key will be generated for you. This is the key the issuer must sign their requests with when they ask the ACS service for a token.

To create an issuer from a command line, you would use the following command:

acm create issuer
-name:MaineReversal
-issuername:MaineReversal
-autogeneratekey

In the configuration browser you’ll need to right-click on the Issuers node and choose Create. Figure 3 shows how to set up your first client, Maine Reversal.

Figure 3. Creating an issuer is easy with the ACS configuration browser. You’ll need to provide both a display name and an official name for the issuer. You can use the tool to automatically create the signing keys.


Setting up an issuer in the system is akin to creating a user. The issuer needs a name (comparable to a username) and a signing key (which is like a password). These are the credentials the issuer will use to request an ACS token.

Token Policy

A token policy defines how you want your tokens to be created. Because token-based systems can be vulnerable to token-replay attacks, you’ll first want to set a lifetime timeout for the token. This is expressed in seconds. When the token is created, it’ll be stamped with the time when the token will expire. Once it’s expired, the token will be considered invalid and won’t be accepted by a service. You have to check for this expiration explicitly when you validate the token.

The command for creating a token policy at the command line is as follows:

acm create tokenpolicy -name:StringReversalInc -autogeneratekey

To create a token policy in the configuration browser, right-click on the Token Policy node and select Create. Figure 4 shows the Create New Token Policy dialog box, where you can create a policy for your string service.

Figure 4. You’ll need to create a token policy. This will determine the lifetime of your tokens, and the key that will be used to sign your ACS tokens.


The second piece of data you’ll need for your token policy is the signing key, which can be generated for you. This is the key that will be used to sign the tokens generated for you by the ACS.

Scopes

A scope is a container that’s tied to a service URI. It brings together the rules that you want applied to your service, as well as the token policy you want used for that service.

To create a scope at the command-line level, you’ll need the ID of the token policy you want to assign to the scope. You can get the tokenpolicyid from the output of the create tokenpolicy command discussed in the previous section. This is the command for creating a scope:

acm create scope -name:StringServiceScope
-appliesto:http://localhost/processstring
-tokenpolicyid:tp_4cb597317c2f42cba0407a91c2553324

When you’re using the configuration browser, you won’t need to provide the token policy ID—you’ll be able to choose it from the drop-down list. You can associate a policy to a namespace by creating a scope, as shown in figure 5.

Figure 5. It’s easy to create a scope. A scope acts as a container for a set of rules for your service. It also associates a token policy with the service. You’ll need to define the URI for the service the scope applies to.


There are several advanced uses for scopes . These include managing a large number of service endpoints with a few scopes, and chaining namespaces together for delegation.

Rules

Rules are the heart of the ACS system. When a token is created by ACS, the rules for the related scope are executed. This is the process that allows you to transform the consumer’s request into something your application can act on. Rules can also be used to create claims out of thin air, and put them in the resulting token.

For example, suppose you wanted to place a claim in the token that represents the consumer’s customerid, to make it easier for your service to identify the account the request is related to. You could create a rule that says, “If this is for issuer MaineReversal, add a claim called customerid with a value of 31415.” Figure 6 shows how you could create this rule.

Figure 6. Creating a rule to insert a claim that includes the customer’s customerid. In this case, you’re relying on the issuer of the inbound request to know which customer it is.


Another rule you could use would assign a new role value based on mappings you’ve worked out with the customer. Perhaps their system tracks their users with a role of ServiceManager—this would be a group the user belongs to at Maine Reversal. Your system doesn’t know that role name, and you don’t want to add all of your customers’ role types to your system—that would get very complex very quickly. The rule in figure 7 creates the roles claim with the manager value.

Figure 7. Creating a rule that substitutes the inbound roles claim for a new one. Using this rule, you can map the ServiceManager role value that your system doesn’t know to one your system does know—manager.


You can then create a rule that finds a claim called roles with a value of Sales-Manager, and replaces it with a claim called roles that has a value of manager. In this way you’ve moved the customer configuration and mapping out of your service and into the authorization service where it belongs.

Creating a rule at the command line is a little more complex than using the configuration browser:

acm create rule -name:MaineReversalMap -scopeid:scp_e7875331c2b880607d5709493eb2751bb7e47044 -inclaimissuerid:iss_6337bf129f06f607dac6a0f6be75a3c287b7c7fa -inclaimtype:roles -inclaimvalue:ServiceManager -outclaimtype:roles -outclaimvalue:manager

To find the IDs of the scope and issuer, you can use these commands: acm getall scope and acm getall issuer.

8. Putting it all together

You’ve come a long way in stopping illicit use of your service. Now you can control who uses it and how they use it. You’ve updated your service to consume tokens, you’ve updated the client to submit tokens with service requests, and you’ve prepared the ACS service with your configuration.

How does this all work? In this simple scenario, the client requests an access token from ACS, providing its secret key and issuer name. ACS validates this and creates a token, using the scope rules you set up to create claims in the new token. The client then attaches the token to the message in the authorization header.

Figure 8 should look familiar; it’s much like the DMV example, but it shows the technical actors and how they interact.

Figure 8. How the three actors work together to securely access a REST service. The service configures ACS; the client asks for a token; ACS creates a token, based on rules; and then the client submits this token with its service request.


When your service finally receives the message, you’ll grab the token from the header and verify it. You want to make sure that it’s valid and hasn’t been tampered with. Once you trust it, you can make decisions on what to do.

In our example, you can take the customerid value and verify that they’re still a paying customer, and if so, respond to their request. You can stop using the token at this point and respond like normal, or you can shred the token and use the claims throughout the application.

If you were protecting an ASP.NET website instead of a REST-based WCF service, you could take those claims, put them in a class that implements IPrincipal, and use the class to make role decisions throughout your code.

We’ve finished a quick lap around ACS. ACS’s sibling is the Service Bus, which will let us connect anything to anywhere, with just a little bit of WCF and cloud magic.

Other -----------------
- Example: A return to our string-reversing service (part 3) - Sending a token as a client & Attaching the token
- Example: A return to our string-reversing service (part 2) - Accepting tokens from ACS & Checking the token
- Example: A return to our string-reversing service (part 1) - Putting ACS in place & Reviewing the string-reversal service
- Connecting in the cloud with AppFabric : Controlling access with ACS
- Joining dynamic and infrequently changing data together
- Enterprise Service Bus with BizTalk Server and Windows Azure : Mapping the Microsoft Platform to the Enterprise Service Bus Pattern
- Enterprise Service Bus with BizTalk Server and Windows Azure : Governance Considerations
- Enterprise Service Bus with BizTalk Server and Windows Azure : Cloud-Enabling the ESB with Windows Azure
- Working with the Table service REST API : Querying data (part 3) - Filtering data with LINQ & Selecting data using the LINQ syntax
- Working with the Table service REST API : Querying data (part 2) - Querying with LINQ & Filtering data with the REST API
 
 
25 Inspiring Game of Thrones Quotes
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
programming4us programming4us
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
 
programming4us
Natural Miscarriage
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Game Trailer