Logging into SharePoint 2010 using Windows Azure Access Control Services (ACS)

  • Article

An organisation's Internet presence shouldn't just be a simple "static" website that provides information to end-users.  It should also be a means for those end-users to interact with the business - even if it's for simple things such as a change of address, or to view their latest statement.  In addition, it's possible to use the Internet site to interact with partners - other organisations that your business works with (such as advertising agencies, plumbers, architects, etc).

 

Once a customer has logged into an SharePoint 2010 portal it is far easier to create more engaging experiences for them by providing account details, graphs, charts and analytics – as well as enabling the customer to use forms based functionality to interact with the business in a transactional sense.

  • Customer and partner portals are viewed as a key enabling mechanism to permit businesses with an ability to create deep customer loyalty and facilitate advanced solutions such as:
  • Customer self-service portals (for example service portals, wiki's and Microblogs)
  • Advanced customer workflow
    Maps
  • Search driven websites where information is rapidly surfaced in response to user queries
  • Personalized websites that remember the interests products and services that customer uses or owns and modifies the site presentation accordingly to make these easier to find or promote related products

I've collated a list of references and overview information below to aid in creating these customer and partner portals using SharePoint 2010.

 

Information References:

Customer references:

 

 

 

Many users already have accounts with identity providers used to authenticate users for one or more applications and websites. Social networks such as Facebook, and email and service providers such as Windows Live ID and Google, often use a single sign-on model for users that supports authentication for several applications. Users increasingly expect to be able to use the credentials for these identity providers when accessing other applications.

Windows Azure Access Control Service (ACS) offers a way to outsource authentication and decouple your application from all the complexity of maintaining a direct relationship with all the identity providers you want to tap from. ACS takes care of engaging every identity provider with its own
authentication protocol, normalizing the authentication results in a protocol supported by the .NET framework tooling (namely the Windows Identity Foundation technology, or WIF) regardless of from where the user is coming from. WIF allows the configuration of ACS as the authentication manager for the application; from that moment on ACS takes care of everything, including providing a UI for the user to choose among all the recognized identity providers.

 

The main features of ACS are as listed below:

· Integrates with Windows Identity Foundation (WIF) and tooling

· Out-of-the-box support for popular web identity providers including: Windows Live ID, Google, Yahoo, and Facebook

· Out-of-the-box support for Active Directory Federation Services 2.0

· Support for OAuth 2.0 (draft 13), WS-Trust, and WS-Federation protocols

· Support for the SAML 1.1, SAML 2.0, and Simple Web Token (SWT) token formats

· Integrated and customizable Home Realm Discovery that allows users to choose their identity provider

· An OData-based Management Service that provides programmatic access to ACS configuration

· A Web Portal that allows administrative access to ACS configuration

 

 

ACS is an issuer that can make use of many of identity providers by redirecting the user to the appropriate location to enter credentials, and then using the claims returned from that identity provider to issue a token to applications. ACS can also be used to supplement a local issuer by retrieving claims from a social networking or email provider and passing these to the local issuer for it to issue the required token. ACS effectively allows a broad range of identity providers to be used for user authentication, both in conjunction with a local issuer and when no local issuer is available.

 

ADFS 2.0 is able to act as a centralized hub for managing user identity and trust relationships between applications, web services and, by extension, organizations. User identity is typically expressed as claims, which are documented in SAML, a type of specially formatted, digitally signed XML. As long as applications can “speak” one of the web standards defined by  (WS-Trust or WS-Federation), they can consume from or provide identity to ADFS 2.0. This is implemented in ADFS 2.0 via two kinds of trust relationships: Claims Provider Trusts and Relying Party Trusts. My previous post involved configuring a Relying Party Trust for a claims-enabled web application in SharePoint 2010 with claims being provided by ADFS 2.0 after users authenticate via Windows Integrated authentication. A Claims Provider Trust allows for that authentication process to be extended to other internal or external identity providers.