1 / 26

.NET Services Access Control Across the .NET Services

BB55. .NET Services Access Control Across the .NET Services. Justin Smith Sr. Program Manager Microsoft Corporation. Azure ™ Services Platform. Microsoft Dynamics CRM Services. Microsoft SharePoint Services. Agenda. Motivation .NET Services 10 minute tour

cytheria
Télécharger la présentation

.NET Services Access Control Across the .NET Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. BB55 .NET ServicesAccess Control Across the .NET Services Justin Smith Sr. Program Manager Microsoft Corporation

  2. Azure™ Services Platform Microsoft Dynamics CRM Services Microsoft SharePoint Services

  3. Agenda • 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

  4. .NET Services in a Slide • 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

  5. Common Access Control Model • 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 NOTE: The .NET Service Bus and the .NET Workflow Service share code for token processing

  6. How They Fit Together What can they do? Integrate Who is the caller? Orchestrate Your Customers Your App <Any ID Provider> ServiceBus WF Access Control Service Live ID Users UI Data XYZ Domain Users Store

  7. 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

  8. Access Control Interactions 3. Map input claims to output claims based on access control rules 1. Define access control rules for a customer Your .NET Access Control Service STS (Managed STS) 0. Cert|Secret exchange; periodically refreshed 4. Send Token (RSTR) (output claims from 4) 6.Claims checked in Relying Party 2. Send Claims (RST) Relying Party (Service Bus, Your App, etc.) Requestor (Your Customer) 5. Send Message w/token

  9. Access Control Approach • .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

  10. Demo .NET Services & Access Control Service Tour Justin Smith

  11. .NET Service Bus Scopes • .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 Foo/ http://servicebus.windows.net/services/ Bar/ Baz/

  12. .NET Service Bus Token Processing • 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

  13. ServiceBus RSTs • .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)

  14. Demo Access Control in the .NET Service Bus Justin Smith

  15. .NET Workflow Service Scopes • .NET Workflow Service uses a namespace to structure resources and endpoints • Model similar to ServiceBus • Includes HTTP endpoints Foo/ http://workflow.windows.net/workflowshttp/ Bar/ Baz/ Foo/ http://workflow.windows.net/workflows/ Bar/ Baz/

  16. Workflow Token Processing • .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

  17. Long Running Behavior • 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

  18. Demo Access Control in the .NET Workflow Service Justin Smith

  19. Usage Patterns • Specifics driven by the requirements of your application • Common Patterns: • Use a Service Account to access .NET Services, handle user AuthN/AuthZ independently • 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

  20. Managing Scopes And Rules • 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

  21. Other Sessions • .NET Services Sessions • Other Identity Sessions

  22. Resources • .NET Services SDK • Marketing Portal • Dev Center Portal • Forums

  23. Evals & Recordings Please fill out your evaluation for this session at: This session will be available as a recording at: www.microsoftpdc.com

  24. Q&A Please use the microphones provided

  25. © 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.

More Related