View
219
Download
1
Category
Tags:
Preview:
Citation preview
.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.
Recommended