Welcome Guest! To enable all features please try to register or login.
Single Sign On (SSO) Solution in Azure for additional providers
Mohammed Rashid
#1 Posted : Monday, December 2, 2013 8:39:04 PM(UTC)
Rank: Member

Groups: Registered
Joined: 5/1/2012(UTC)
Posts: 16
Location: Bangalore

Was thanked: 3 time(s) in 3 post(s)
Hello All,
I have a requirement to implement Windows Azure Access Control Service for Single Sign On (SSO) for Facebook and LinkedIn. Windows Azure currently supports only 3 social providers Microsoft, Yahoo and Google. Has anyone got any solution implementing FB or LI?

Thanks & regards,

Mohammed Rashid
#2 Posted : Wednesday, January 22, 2014 4:35:26 PM(UTC)
Rank: Member

Groups: Registered
Joined: 5/1/2012(UTC)
Posts: 16
Location: Bangalore

Was thanked: 3 time(s) in 3 post(s)
Just in case some one needs the info, I have provided here. SSO can be achieved by using Windows Identity Foundation.

Windows Identity Foundation (WIF) is a set of .NET Framework classes. It is a framework for implementing claims-based identity in your applications. Architecturally using claims-based identity gets your application out of the authentication business. Single sign-on is much easier to achieve, and your application is no longer responsible for:

  • Authenticating users.

  • Storing user accounts and passwords.

  • Calling to enterprise directories to look up user identity details.

  • Integrating with identity systems from other platforms or companies.

Instead your application uses a claim that arrives to your application as a security token from an issuing authority. A security token service (STS) is the plumbing that builds, signs, and issues security tokens according to the interoperable protocols. Your application is the relying party.

Claim - A claim is some information that your application need to know about a user. For example, a user’s name or email address or in the sales organization. Your application will accept the claim from Security Token. In a Web service, these claims are carried in the security header of the SOAP envelope. In a browser-based Web application, the claims arrive via an HTTP POST from the user’s browser, and may later be cached in a cookie if a session is desired.
Issuing Authority is a Web application or Web service that knows how to issue security tokens. In the scenario of claims-based identity, the issuing authority is responsible for issuing the proper claims (such as name and email or whether the person is in the sales organization.)

Security Token Service (STS) - STS is trusted by both the client and the Web service to provide interoperable security tokens.
Relying Party - That’s your application or Web service. You can see it described as claims aware application or claims-based application.
SAML Token - Most STSs today issue SAML (Security Assertion Markup Language) tokens. SAML is an industry-recognized XML vocabulary that can be used to represent claims in an interoperable way.

There are many scenarios. But in the one I chose, a user points her browser at a claims-aware Web application (relying party). The Web application redirects the browser to the STS so the user can be authenticated.
The STS, wrapped by a simple Web application that reads the incoming request, authenticates the user via standard HTTP mechanisms, and then creates a SAML token and emits a bit of JavaScript that causes the browser to initiate an HTTP POST that sends the SAML token back to the relying party.

The SAML token in the POST body contains the claims that the relying party requested.

Your application takes the SAML token and using Windows Identity Foundation, uses a few lines of code to open up the token and extract the claims. Now you have access to the requested data, such as name, email, and whether or not the person is in the sales organization.

There are many other scenarios. This one uses WS-Trust.

You don’t have to worry about what domain or security realm your user happens to be part of. In fact, you can support Facebook identity or Windows Live or Google ID or a claim from a user based on their active directory. Using claims based identity makes it a lot easier to federate identity with other platforms or organizations.

Windows Identity Foundation Object Model for Claims
When you build a relying party with WIF, you’re shielded from all of the cryptographic heavy lifting that WIF (and its underlying WCF plumbing) does for you. It decrypts the security token passed from the client, validates its signature, validates any proof keys, shreds the token into a set of claims, and presents them to you via an easy-to-consume object model.
In your code you ask the token for each claim you need.

Here’s a sample that returns an email address.
protected string GetUserEmail(object sender, EventArgs e)
IClaimsIdentity id =

// you can use a simple foreach loop to find a claim...
string usersEmail = null;
foreach (Claim c in id.Claims) {
if (c.ClaimType == ClaimTypes.Email) {
usersEmail = c.Value;
return usersEmail;

The code can assume that the assumed the caller was authenticated and that her and email address had been sent as claims. The reason this program can make these assumptions is because it has a web.config file that uses the WS-Federation Authentication Module (FAM) from WIF and configures it with the address of an STS that can authenticate the user and supply these types of claims.

FAM is an HttpModule that is specifically designed to make it easy to build federated claims-aware Web applications using ASP.NET 2.0.

So you need some information in your web.config that is explained in the Microsoft Windows Identity Foundation (WIF) Whitepaper for Developers.

WIF offers built-in Visual Studio project template for creating a claims-aware ASP.NET application or claims-aware WCF services. So you can have an excellent starting point.

Hope that's useful.

Thanks & regards,
Rss Feed   Atom Feed
Users browsing this topic
Guest (4)
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAFPro Theme Created by Jaben Cargman (Tiny Gecko)
Powered by YAF 1.9.5 RC1 | YAF © 2003-2010, Yet Another Forum.NET
This page was generated in 0.133 seconds.