I had been looking at Windows Azure Access Control Service (ACS) with an interesting eye recently, thinking about some of the different integration options. There’s always lots of chatter about claims authentication with SharePoint 2010, and how to integrate ADFS, Windows Live, Facebook, etc. ACS (also known as AppFabric ACS to you Azure purists / marketing people) is rather cool because it includes “connectors” for these common identity providers out of the box. When you set up an ACS namespace (think of it like an account with connectors and configuration settings), you have simplified and streamlined connectivity to ADFS 2.0, Windows Live, Yahoo, Google and Facebook. The lazy programmer in me thinks hey, there must be something goin’ on there so I decided to look into it from a couple of different angles. I’m going to describe the first one in this post.
For this scenario I really just wanted to establish a trust directly between SharePoint 2010 and ACS. I wanted to be able to use ADFS, Windows Live, Yahoo and Google accounts to authenticate and get into my SharePoint site. I didn’t include Facebook because social computing is really not my thing (this blog’s as close as I get) so I don’t have a Facebook or Twitter account because I’m really not interested in frequently sharing pointless information with the world at large (“Puffy just had 3 kittens – Adorable!!”). I will NOT be explaining how to get a Windows Azure account, create an Access Control Service namespace, how to manage ACS, etc. – there should be reams of info out there from the Windows Azure folks so I’m not going to try and reinvent that.
What I am going to describe is the process of setting up the various trusts, certificates, and configuration necessary to get all this stuff working together. At the end I’ll include some screenshots of me logged in with identities from each of those providers. Here are the steps to get connected:
Add An Identity Provider for ADFS
That’s pretty much all you need to do to create your Identity Provider in ACS.
3. Add A Relying Party for SharePoint
4. Create the rules for the Relying Party
5. Create a Relying Party for ACS in ADFS
6. Configure the SharePoint Trust with ACS
<RoleDescriptor xsi:type="fed:SecurityTokenServiceType" protocolSupportEnumeration="http://docs.oasis-open.org/wsfed/federation/200706" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:fed="http://docs.oasis-open.org/wsfed/federation/200706">
Copy the data out of the X509Certificate element and paste it into notepad. Save it with a .CER file extension (the encoding should be ANSI); for purposes of this post let’s assume you call the file C:\AcsTokenSigning.cer. This is the token signing certificate for ACS.
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\AcsTokenSigning.cer")
New-SPTrustedRootAuthority -Name "ACS Token Signing" -Certificate $cert
At this point you should be ready to hit the site and give it a try. Remember that you’ll need to configure the site collection administrator to be one of the email addresses that one of the identity providers will return so you can log into the site. Once in there you can add email addresses or role claims from providers to SharePoint groups just as you would normally expect to do.
The one caveat to remember again, for now, is Windows Live ID. As stated previously in this post, you won’t really have a valid email address for Windows Live so you will need to add what they call the PUID to your SharePoint group. For testing purposes, the easiest way to get this is to log in using Windows Live ID, and then you will reach the page in SharePoint that says you are logged in as “foo” and access is denied. From there you can copy the PUID, login as an admin user, add the PUID to a SharePoint group and you should be good to go. I haven’t even looked at what kind of directory options, if any, are available for Windows Live ID (I’m guessing probably none). But it’s a start so we can move this proof of concept along. Now that we’ve done that, here’s what it looks like logging into my site using each of these identity providers:
Windows Live ID
Steve, this is tasty stuff and I think based on this we're going to use ACS with our in-the-works SharePoint deployment. What's your take on the use of Forefront UAG in there? (technet.microsoft.com/.../dd861393.aspx) Can you tie UAG to ACS just like UAG to ADFS?
SharePoint <--> UAG <--> ACS <--> ADFS / WLID / Google / Yahoo / Facebook
Hey Darin, I've never tried...I'm sure it's possible, although I'm not entirely sure I follow the use case for UAG in this scenario. Not diggin' on what you're saying, I'm just not following the need.
In this example, when Sharepoint is using ACS as Identity Provider only, why do I need to "Add A Relying Party for SharePoint" in ADFS?
The chain is like Sharepoint --> ACS --> Windows Live, Facebook, ADFS. Since we dont need to do something special for Windows Live and Facebook in this scenario, why an exception for ADFS?
I would appreciate if you can reply to my question on my mail email@example.com
I know you're leaving the Azure stuff up to the Azure team, but I'm struggling to understand why you would do this. Does ACS provide a better way to use LiveID and ADFS or is it just needed for Yahoo and Google? What does the login screen look like?
hi steve we used this blog to create our claims based sharepoint application but when we run it selecting adfs 2.0 for sign in it gives the error as : the token issuer is not a trusted issuer
can u please help me in this
An access control system provides a high level of safety in your homes and offices. An access control system maintains the restricted areas protected from intruders and permit access only to authorized personnel. An access control system detects even the input of staff time. To protect and safeguard the people, documents and equipment of a specific facility.
An access control system is very functional in buildings with multiple APs. Inputs and outputs through these doors are controlled by the access control system using different types of security devices. The most common is that the panel numbered buttons or a touch screen connected to the lock and let the system function of the door. A specific PIN code is entered by the employee and validated by the access control system.
The second device employed by the access control system is the Magstripe Reader, which is called the swipe card reader. The employee was issued a coded card; he or she will sweep the door lock off. Often, the encoded card also serves as his employee.
Access control systems also use Proximity readers and Long Range Readers. These sensors can detect a coded card without the need for sweeping. The former detects the card at a short distance of about 100 millimeters, while the latter may feel a ticket at a distance of about 1 meter. As fast and non-contact methods of entry, these designed to meet the Disability Discrimination Act.
this is absolutely working fine ,but i was trying to customize the acs default login page and access through the sharepoint application,It works for asp.net application but does'nt work for sharepoint.
Can you please help me in this.
great article! it may be 3 years old but it seems the stuff it covers is more "in fashion" than ever ;-)
however, when i was working through the topic some time ago i came across some behavior in SharePoint that i think was weird. i used an up to date SP Foundation 2010 and i was not able to add users to any of the default groups (member, visitor, owner), be it
an AD user or one of my external users. the weird part is that the buttons did not seem to work at all. i could type in the search bar and find all of the users perfectly fine (both AD and external) but when i click the "Add -->" button it does not fill the
line and the "OK" button stays grayed out. double clicking on the user also does not work.
so, is this because foundation? is it a bug? did i miss something? have you had this before?
thanks a bunch!
I tried it in Firefox and it worked. however, i didn't search for any config issues in IE yet.