I had been meaning to actually read Vittorio’s post from back in early August regarding the new version of Windows Azure AppFabric ACS and I was finally able to do it last weekend. I’m really glad I did. If you’re unfamiliar with Windows Azure ACS and what it does, you might want to check out the interview with Justin Smith, the program manager for ACS. Essentially, ACS acts in a very similar role as ADFS 2.0 but it’s hosted as part of the Azure public cloud. Like ADFS 2.0, it can be used as a centralized “authentication hub” and this new version includes out-of-the-box support for Yahoo!, Google, Facebook, ADFS 2.0, and (of course) Windows Live ID. Vittorio even created nice diagram explaining the protocols and interfaces.
SharePoint 2010 isn’t specifically called out in any of these posts, but since I know that it works great with WS-Federation and SAML 1.1 tokens, I thought I’d give it a shot and set up ACS as an identity provider for my development instance. The process turned out to be ridiculously easy. If you have a SharePoint 2010 web application in claims mode, I’m willing to bet you’ll be able to leverage ACS v2 in your environment in 30 minutes.
To start off, you need to create an account on AppFabric labs. This is completely free and will give you access to the full functionality of ACS v2. Once you define your service namespace and project, you’ll be ready to manage ACS via the handy user interface.
For starters, I have to say I’m impressed with the clarity this portal provides. You can see a logical progression from defining identity providers all the way through configuring the token signing certificate.
Google is probably the most straightforward and (possibly the most) common identity provider out there. So selecting that as an IP is a great place to start with testing. There isn’t much to configure here except for an optional URL for an image that the user will click for authentication.
After that, I defined my test SharePoint site as a Relying Party Application. Again, there really isn’t anything earth shaking here. You can see in the following screenshot that I selected the SAML 1.1 token format and defined the return URL to be the standard /_trust/ directory for the claims-mode web application. Anyone who has configured claims authentication on SharePoint 2010 before should be well familiar with that path.
You can see from the above screenshot that I’ve applied a rule group specifically for this relying party application. For simplicity, I simply decided to pass through all claims from the identity providers all the way back to SharePoint. However, notice there are opportunities to do some basic claims transform options.
Lastly, I uploaded a token signing certificate that I had created earlier. For testing purposes, it’s fine to use something like SelfSSL or MakeCert to generate the certificate. Azure ACS will use this certificate to digitally sign the SAML 1.1 token.
And that’s pretty much it on the ACS portal side. Next we need to define AppFabric ACS as an identity provider in SharePoint 2010. This is accomplished with the following PowerShell script.
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“c:your_token_signing.cer“)
$map1 = New-SPClaimTypeMapping “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress” -IncomingClaimTypeDisplayName “Email” -SameAsIncoming
$realm = “your-realm”
$signinurl = “https://your-service-namespace.accesscontrol.appfabriclabs.com/v2/wsfederation”
New-SPTrustedIdentityTokenIssuer -Name “Azure ACS” -Description “Windows Azure ACS v2” -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType
New-SPTrustedRootAuthority -Name “Azure Test Token Signing” -Certificate $cert
NOTE: Be sure that the value for $realm matches the setting in “Relying Party Application” screen (above). Also note that in this example, I’m only defining the “emailaddress” claim. The last line of the PowerShell script is important to ensure SharePoint 2010 will trust the certificate being used to sign the token.
Before testing things out, we need to be sure that users authenticated via the “Azure ACS” claims provider actually have rights in SharePoint. In this case, I decided to be magnanimous and grant “All Users” membership to the “Visitors” group of my test Intranet site.
The rest is very straightforward. After signing out of SharePoint, I re-load the page and select “Azure ACS” as the Identity Provider.
Next, I’m presented with a screen where I get to pick any provider that was previous configured in ACS. In this case, I’m picking Google. Since I previously provided an image URL when I set Google up as an Identity Provider, I see the Google Accounts logo. As I mentioned, this is not a requirement, but may make sense to help users quickly select the provider they want to use or are comfortable with.
And you can see I’m granted access to the site with viewer access. The “emailaddress” claim is used to establish my identity.
Facebook works great with Azure ACS as well. If you want to test this out, handy instructions are provided here.
I got this done quickly and without needing to write a line of code. In my mind, this is an excellent example of how well things have progressed (in less than one year) in the identity space. I’m impressed! Stay tuned to hear when ACS v2 gets launched into production.
SharePoint 2010 isn’t specifically called out in any of these posts, but since I know that it works great with WS-Federation and SAML 1.1 tokens, I thought I’d give it a shot and set up ACS as an identity provider for my development instance. The process turned out to be ridiculously easy. If you have a SharePoint 2010 web application in claims mode, I’m willing to bet you’ll be able to leverage ACS v2 in your environment in 30 minutes.
To start off, you need to create an account on AppFabric labs. This is completely free and will give you access to the full functionality of ACS v2. Once you define your service namespace and project, you’ll be ready to manage ACS via the handy user interface.
For starters, I have to say I’m impressed with the clarity this portal provides. You can see a logical progression from defining identity providers all the way through configuring the token signing certificate.
Google is probably the most straightforward and (possibly the most) common identity provider out there. So selecting that as an IP is a great place to start with testing. There isn’t much to configure here except for an optional URL for an image that the user will click for authentication.
After that, I defined my test SharePoint site as a Relying Party Application. Again, there really isn’t anything earth shaking here. You can see in the following screenshot that I selected the SAML 1.1 token format and defined the return URL to be the standard /_trust/ directory for the claims-mode web application. Anyone who has configured claims authentication on SharePoint 2010 before should be well familiar with that path.
You can see from the above screenshot that I’ve applied a rule group specifically for this relying party application. For simplicity, I simply decided to pass through all claims from the identity providers all the way back to SharePoint. However, notice there are opportunities to do some basic claims transform options.
Lastly, I uploaded a token signing certificate that I had created earlier. For testing purposes, it’s fine to use something like SelfSSL or MakeCert to generate the certificate. Azure ACS will use this certificate to digitally sign the SAML 1.1 token.
And that’s pretty much it on the ACS portal side. Next we need to define AppFabric ACS as an identity provider in SharePoint 2010. This is accomplished with the following PowerShell script.
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“c:your_token_signing.cer“)
$map1 = New-SPClaimTypeMapping “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress” -IncomingClaimTypeDisplayName “Email” -SameAsIncoming
$realm = “your-realm”
$signinurl = “https://your-service-namespace.accesscontrol.appfabriclabs.com/v2/wsfederation”
New-SPTrustedIdentityTokenIssuer -Name “Azure ACS” -Description “Windows Azure ACS v2” -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType
New-SPTrustedRootAuthority -Name “Azure Test Token Signing” -Certificate $cert
NOTE: Be sure that the value for $realm matches the setting in “Relying Party Application” screen (above). Also note that in this example, I’m only defining the “emailaddress” claim. The last line of the PowerShell script is important to ensure SharePoint 2010 will trust the certificate being used to sign the token.
Before testing things out, we need to be sure that users authenticated via the “Azure ACS” claims provider actually have rights in SharePoint. In this case, I decided to be magnanimous and grant “All Users” membership to the “Visitors” group of my test Intranet site.
The rest is very straightforward. After signing out of SharePoint, I re-load the page and select “Azure ACS” as the Identity Provider.
Next, I’m presented with a screen where I get to pick any provider that was previous configured in ACS. In this case, I’m picking Google. Since I previously provided an image URL when I set Google up as an Identity Provider, I see the Google Accounts logo. As I mentioned, this is not a requirement, but may make sense to help users quickly select the provider they want to use or are comfortable with.
And you can see I’m granted access to the site with viewer access. The “emailaddress” claim is used to establish my identity.
Facebook works great with Azure ACS as well. If you want to test this out, handy instructions are provided here.
I got this done quickly and without needing to write a line of code. In my mind, this is an excellent example of how well things have progressed (in less than one year) in the identity space. I’m impressed! Stay tuned to hear when ACS v2 gets launched into production.
