This project is read-only.

Choosing Your Application Scenario

- J.D. Meier, Paul Enfield.

Scenario Groups Summary

ASP.NET Applications

ASP.NET applications encompasses web based applications with server-side processing performed by ASP.NET.

Forms Authentication to Azure Storage
Use this scenario if:
  • You have no existing user store
  • You have an existing solution based on the ASP.NET membership system
  • You wish to leverage an existing established an tested authentication system
  • You are metering expenditures on a per-transaction basis, or on a bandwidth basis, or in a total storage size utilized
  • You do not have a need to extract business intelligence from the user store
  • You do not have multiple applications that will need to share the same authentication logic
  • You do not have authorization needs that extend beyond simple user names and groups/roles
  • You do not have a need to coordinate user stores with partners or shared user stores

Forms Authentication to SQL Azure
Use this scenario if:
  • You have no existing user store
  • You have an existing solution based on the ASP.NET membership system
  • You wish to leverage an existing established an tested authentication system
  • You have a need to extract business intelligence from the user store
  • You do not have multiple applications that will need to share the same authentication logic
  • You do not have authorization needs that extend beyond simple user names and groups/roles
  • You do not have a need to coordinate user stores with partners or shared user stores


ASP.NET to Active Directory with Claims
Use this scenario if:
  • You have an existing user store hosted in Active Directory
  • You are seeking a Single Sign-On (SSO) solution
  • You have multiple applications that will need to share the same authentication logic
  • You wish to isolate authentication logic from application code
  • You have authorization needs that extend beyond simple user names and groups/roles, or would like to build authorization around claims
  • You have security requirements that prohibit the transfer of user credentials across the wires
  • You may have a future need to coordinate user stores with partners or shared user stores
  • You wish to leverage existing tools or infrastructure supporting user provisioning
  • You have a need to integrate the authentication with RESTful services
  • Exposing the AD user store to the public internet via port 80 or 443 is permissible.

ASP.NET to AD with Claims, Federated Partner
Use this scenario if:
  • You have an existing user store hosted in Active Directory
  • You are seeking a Single Sign-On (SSO) solution
  • You have multiple applications that will need to share the same authentication logic
  • You wish to isolate authentication logic from application code
  • You have authorization needs that extend beyond simple user names and groups/roles, or would like to build authorization around claims
  • You have security requirements that prohibit the transfer of user credentials across the wires
  • You have an immediate need to coordinate user stores with partners or shared user stores
  • You wish to leverage existing tools or infrastructure supporting user provisioning
  • You have a need to integrate the authentication with RESTful services
  • Exposing the AD user store to the public internet via port 80 or 443 is permissible.

WCF Services

WCF Services groups web services based on SOAP and built using the Windows Communication Foundation.

ASP.NET to WCF
Use this scenario if:
  • You have an ASP.NET application that will connect to a WCF service
  • You will be hosting both the ASP.NET application, and the WCF service in Windows Azure
  • The WCF service does not require fine-grained authorization
  • The WCF service does not require message based security
  • The ASP.NET application will authenticate users
  • The ASP.NET application will be required to authorize access to the WCF service
  • A common identity will be used for all WCF connections
  • The WCF service does not need to uniquely identify individual connections
  • You do not require user level auditing at the WCF service level

On-site ASP.NET to WCF on Windows Azure
Use this scenario if:
  • You have an existing ASP.NET application hosted on-site
  • You will be hosting the WCF service in Windows Azure
  • The WCF service requires fine-grained authorization
  • The WCF service requires message based security
  • The ASP.NET application will authenticate users
  • The original caller’s identity will be used to authenticate against the WCF service
  • The WCF service needs to uniquely identify individual connections
  • You require user level auditing at the WCF service level
  • It is permissible to send the user credentials over the wires

ASP.NET to WCF with Claims
Use this scenario if:
  • Users will authenticate against the ASP.NET application using claims from a SAML token
  • You have user claims provided by a Secure Token Service (STS)
  • You will host the WCF service in Windows Azure (perhaps remove this as it isn’t unique to Azure?)
  • You need to connect to the WCF service using a SAML token
  • You wish to authenticate and authorize in the WCF service using claims
  • The WCF service requires the claims/identity of the original caller

REST Services

REST services are services built to support a RESTful interface. These can be implemented using WCF or as a web page.

REST Service with AppFabric Access Control
Use this scenario if:
  • You have REST service hosted in Windows Azure
  • You need to authenticate access to the REST service
  • You will authenticate and authorize within the REST service using claims
  • You may have the need to leverage claims in SAML tokens

Data Storage

Data scenarios cover a wide range of scenarios in which data is accessed. The data may be hosted on-site or remotely in the cloud. The data may have a service interface, or accessed directly from the application.

ASP.NET to Azure Storage
Use this scenario if:
  • You are metering expenditures on a per-transaction basis, or on a bandwidth basis, or in a total storage size utilized
  • Your data is not relational
  • Your data only needs to be accessed on 1 or 2 keys
  • You have no existing user store
  • The auditing of your data access does not require the identity of the original caller
  • The data will not be front-ended with a service interface

ASP.NET to SQL Azure
Use this scenario if:
  • Your data is relational
  • You have existing logic or investment in SQL Server
  • You have no existing user store
  • Your user administration will be done on SQL Server
  • The data will not be front-ended with a service interface

ASP.NET On-Site to Data on Windows Azure through WCF
Use this scenario if:
  • You want to host your data in the cloud
  • Your data is relational
  • You have existing logic or investment in SQL Server
  • Your user administration is on-site

ASP.NET on Windows Azure to SQL On-Site
Use this scenario if:
  • You have existing data hosted in SQL Server on-site
  • You have requirements that prohibit hosting of data in the cloud
  • You are prohibited from exposing the data through the corporate firewall
  • Your data consumption needs are not highly performant
  • Your ASP.NET client application is built to handle data delivery latency

Benefits and Considerations Matrix

ASP.NET Applications

Forms Auth to Azure Storage
Benefits Considerations
* Lower cost per megabyte storage ratio * Limited queryability on user store
* Lower cost per transaction * Non-relational data
* Lower cost per megabyte transferred * Providers are in sample form
* Extensive existing guidance available to leverage * Credentials passed over wire, require encrypted channel (SSL)
* * Potentially decentralized user management may impose user provisioning overhead
* * User store exposed through REST interface
* * Authentication/Authorization is baked into the application


Forms Authentication to SQL Azure
Benefits Considerations
* Extensive existing guidance available to leverage * Credentials passed over wire, require encrypted channel (SSL)
* “out of the box” implementation * Potentially non-centralized user management may impose user provisioning overhead
* Relational data * SQL Azure database size limitations may require partitioning strategy
* Leverages established and tested providers * Authentication/Authorization is baked into the application


ASP.NET to AD with Claims, Federated Partner
Benefits Considerations
* Leverage existing user stores * Corporate user store exposed to public Internet
* Single Sign-On * Preferred deployment pattern will use greater number of Azure services (more instances) which equates to greater cost
* Use of security tokens instead of credentials * Corporate key rollover policies may require re-establishment of trust relationships for which there is no current automated method
* Claims/WS* facilitate abstraction of Auth logic/capabilities *
* Leverage existing tools+infrastructure for user provisioning *
* SAML supported by ACS for claims mapping *


ASP.NET to AD with Claims, Federated Partner
Benefits Considerations
* Leverage existing user stores * Corporate user store exposed to public Internet
* Single Sign-On * Corporate key rollover policies may require re-establishment of trust relationships for which there is no current automated method
* Use of security tokens instead of credentials * Preferred deployment pattern will use greater number of Azure services (more instances) which equates to greater cost
* Claims/WS* facilitate abstraction of Auth logic/capabilities *
* Leverage existing tools+infrastructure for user provisioning *
* De-centralized identity provider(s) *
* SAML supported by ACS for claims mapping *

WCF Services

ASP.NET to WCF
Benefits Considerations
* Only requires server-side X509 certificate * Deployment and packaging strategy will impact communication strategy of WCF service
* ASP.NET authentication is independent of WCF authentication * Course-grained authorization requires authorization logic at application level
* * Uses one-way authentication of the service
* * Authorization logic is tightly coupled to application logic
* * Original caller identity is not flowed to WCF service, prohibiting user level auditing in WCF service


On-site ASP.NET to WCF on Windows Azure
Benefits Considerations
* ASP.NET authentication is independent of WCF authentication * Uses one-way authentication of the service
* Username authentication for WCF service allows for fine grained authorization * Authorization logic is tightly coupled to application logic
* User level auditing in WCF service *


ASP.NET to WCF with Claims
Benefits Considerations
* Authorization logic is loosely coupled to application logic * Trust relationships require more management overhead
* Fine grained authorization is possible in WCF service * Application logic to build required SAML token for impersonation is more complex
* User level auditing in WCF service *
* Permits integration with partner user stores (foreign identity providers) *
* SAML based claims tokens can be mapped to SWT for integration with REST services *

REST Services

REST with AppFabric Access Control
Benefits Considerations
* Leverages claims based authentication and authorization * AD support is achieved by mapping SAML claims to SWT
* Can integrate with Active Directory * This is the primary authentication story for Microsoft technologies. Other approaches would be custom code.
* Can work with partner user stores (identity providers) * Requires the use of AppFabric Access Control which is a separate cost to a base Windows Azure subscription.

Data

ASP.NET to Azure Storage
Benefits Considerations
* Lower cost per megabyte storage ratio * Data is not relational
* Lower cost per transaction * Functionally, only 2 indexes per table
* Lower cost per megabyte transferred * Azure storage data access is over HTTP or SSL
* Forms authentication has extensive existing guidance available to leverage * Data access is occurs at the same authorization level, logic for authorization must occur at application level


ASP.NET to SQL Azure
Benefits Considerations

|* User provisioning in SQL Azure will lead to administrative overhead if it is to be coordinated with on-site user provisioning |
* SQL Membership provides “out of the box” implementation capabilities * SQL Azure has fixed database size increments. Large amounts of data may require partitioning strategy
* Data is relational * SQL Connection should be protected by encrypting the TDS connection
* Many existing SQL tools are leverageable * Synchronizing user provisioning with on-site user provisioning will impose management over head


ASP.NET On-Site to Data on Windows Azure through WCF
Benefits Considerations
* A possible step in migration of application to cloud. * On-site ASP.NET application may need to be deal with data delivery latency
* Facilitates Data as a Service scenario * Connections to WCF occur as service identity.
* * User identity flow through to WCF service would need to be custom coded
* * SQL connection credentials rollover and propagation currently a manual process


ASP.NET on Windows Azure to SQL On-Site
Benefits Considerations
* Usage of AppFabric Service Bus lowers barriers to implementation by working around firewall issues. * Use of Service Bus reduces performance due to overhead imposed by relay architecture
* * Application may need to be tuned to handle data delivery latency


Last edited Jun 5, 2010 at 12:31 AM by paulenfield, version 10

Comments

No comments yet.