Downloaded 11 times
Uploaded byWade Wegner
A Lap Around the Windows Azure AppFabric
The document discusses the integration of caching services and access control within composite applications, particularly focusing on Windows Workflow Foundation (WF) and Windows Communication Foundation (WCF). It mentions key components such as identity providers, relying parties, and several enhancements related to service bus access control. Additionally, it includes links to external resources and highlights important updates and release notes relevant to the year 2011.
A Lap Around the Windows Azure AppFabric
- 8. Caching Service BusAccess Control Integration Composite App (WF, WCF)
- 9.
- 12.
- 17.
- 21.
- 22. Datacenter LOB web service LOB app Partner MobileDevice SB ACS
- 23. Datacenter LOB web service LOB app Partner MobileDevice SB ACS
- 24. Datacenter LOB web service LOB app Partner MobileDevice SB ACS
- 25.
- 29. CTP Caching PDC9/16 CTP Access Control enhancements H12011 General Availability Caching CTP Composite App General Availability Access Control CTP Service Bus enhancements Release Service Bus enhancements TechEd EMEA
- 32.
Editor's Notes
- #18 Relying Party - In identity jargon, we often refer to applica-tions as “Relying Parties,” an expression that refers to the fact that the application relies on one or more IPs to take care of authentication on their behalf Identity Providers – The party that stores user identities e.g. AD, Live ID, Google, etc. Token – Claim – an attribute that’s a part of the token,
- #19 The Client (in this case a browser) requests a resource at the RP. In most cases, this is simply an HTTP GET. Since the request is not yet authenticated, the RP redirects the Client to the correct IdP. The RP may determine which IdP to redirect the Client to using the Home Realm Discovery capabilities of ACS. The Client browses to the IdP authentication page, and prompts the user to login. After the Client is authenticated (e.g. enters credentials), the IdP issues a token. After issuing a token, the IdP redirects the Client to ACS. The Client sends the IdP issued token to ACS. ACS validates the IdP issued token, inputs the data in the IdP issued token to the ACS rules engine, calculates the output claims, and mints a token that contains those claims. ACS redirects the Client to the RP. The Client sends the ACS issued token to the RP. The RP validates the signature on the ACS issued token, and validates the claims in the ACS issued token. The RP returns the resource representation originally requested in (1).