.NET ServicesAccess Control Across the .NET Services

Justin Smith Sr. Program Manager

Microsoft Corporation

BB55

Azure™ Services Platform

Microsoft SharePoint Services

Microsoft Dynamics CRM Services

Motivation .NET Services 10 minute tour .NET Service Bus and .NET

Access Control Service .NET Workflow Service and

.NET Access Control Service Microsoft SQL Data Services and

.NET Access Control Service Usage Patterns

Agenda

Extension of .NET capabilities to the cloud Leverage what you know to do

things that are otherwise pretty hard 3 Services today, more to follow .NET Service Bus – connectivity and fan-out

messaging necessary for many integrations .NET Workflow Service –

reliably run workflows at scale .NET Access Control Service –

authorization based on federated identities

.NET Services in a Slide

The following use the same approach to access control

Microsoft SQL Data Services Accepts both a Username & Password and a

token produced by .NET Access Control Service .NET Service Bus .NET Workflow Service The Portals

Common Access Control Model

NOTE: The .NET Service Bus and the .NET Workflow Service share code for token processing

How They Fit Together

Your CustomersYour App

Acce

ss C

ontr

ol

Serv

ice

<Any ID Provider>

Live ID Users

XYZ Domain Users

Who is the caller?

What can they

do?

UI

Integrate

ServiceBus

Orchestrate

Store

WF

Data

Access Control Moving Parts

Portal A UI for creating and managing

collections of access control rules Client API

Provides a programmatic way to manage collections of access control rules

Service (STS) A hosted service that issues tokens Developers interact with the

service via the “Geneva” Framework

Access Control Interactions

Your .NET Access Control Service STS

(Managed STS)

Relying Party(Service Bus,

Your App, etc.)

2. Send Claims

(RST)4. Send Token (RSTR)

(output claims from

4)

5. Send Messagew/token

0. Cert|Secret exchange; periodically refreshed

Requestor(Your

Customer)

1. Define access control rules for a customer

6.Claims checked

in Relying Party

3. Map input claims to output claims based on access control rules

.NET ServiceBus, .NET Workflow Service and Microsoft SQL Data Services have .NET Access Control Service accounts

These accounts contain scopes and encryption preferences

Rules are automatically added to scopes when new customer accounts are created

The rules are different for the .NET Service Bus, .NET Workflow Service, and the Microsoft SQL Data Service

The .NET Service Bus and .NET Workflow Service grant customer accounts edit permissions on the rules

Access Control Approach

.NET Services & Access Control Service Tour

Justin Smith

Demo

.NET Service Bus uses a namespace to structure resources and endpoints

Each customer account is assigned part of the namespace based on Solution Name

Each Solution Name namespace is a scope in the .NET Access Control Service

The Solution Name owner is granted edit permission on the scope

.NET Service Bus Scopes

http://servicebus.windows.net/services/

Foo/

Bar/

Baz/

The .NET Service Bus requires the token to: Contain the namespace of

the resource being accessed Contain Action claims of Listen and/or Send Be encrypted with the

.NET Service Bus certificate Be valid for the time it is presented

The Solution Name scope is provisioned with 2 rules: Username=Foo Action=Listen Username=Foo Action=Send

Foo can modify these rules as needed

.NET Service Bus Token Processing

.NET Services SDK includes types that extend WCF to request tokens for you Standard endpoint behaviors SolName/Pwd, X509,

CardSpace, Federation, etc. Accessible via the

TransportClientEndpointBehavior type The interaction is based on

WS-Trust 1.3, so many other web services stacks can interact with the .NET Service Bus (e.g., Sun Metro 1.3)

ServiceBus RSTs

Access Control in the .NET Service Bus

Justin Smith

Demo

.NET Workflow Service uses a namespace to structure resources and endpoints Model similar to ServiceBus

Includes HTTP endpoints

.NET Workflow Service Scopes

http://workflow.windows.net/workflows/

Foo/

Bar/

Baz/

http://workflow.windows.net/workflowshttp/

Foo/

Bar/

Baz/

.NET Workflow Service requires the token to: Contain the namespace of

the resource being accessed Contain Action claims of

Read/Write/Execute/Send Be encrypted with the Workflow certificate Be valid for the time it is presented

The Solution Name scope is provisioned with Action rules Read/Write/Execute/Send

You can modify these rules as needed

Workflow Token Processing

Workflows can run for past the lifetime of a normal token

Example: Every day for 6 months, Foo’s workflow needs to send a message to the ServiceBus

Workflow uses a long-lived Authentication (AuthN) token to request Authorization (AuthZ) tokens

Long Running Behavior

Access Control in the .NET Workflow Service

Justin Smith

Demo

Specifics driven by the requirements of your application

Common Patterns:1. Use a Service Account to access .NET Services,

handle user AuthN/AuthZ independently2. Use federation to allow users

to AuthN/AuthZ with Services Approach 1 likely for existing

applications with their own user store Approach 2 fits best in new applications

Usage Patterns

Assumes the federated approach Create new scopes for sets of users

Subordinate to .NET Service Bus and .NET Workflow Service scopes created at provision time

Assign Listen/Send/Execute, etc. based on user scenarios Use the client API in your own

onboarding process for users

Managing Scopes And Rules

.NET Services Sessions Other Identity Sessions

Other Sessions

.NET Services SDK Marketing Portal Dev Center Portal Forums

Resources

Evals & Recordings

Please fill

out your

evaluation for

this session at:

This session will be available as a recording at:

www.microsoftpdc.com

Please use the microphones provided

Q&A

© 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market

conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.