Configuring ADFS Trusts For Multiple Identity Providers with SharePoint 2010

To begin with, start on the ADFS server to which your SharePoint site has the trust (we'll call it RP).

1. Open the federationmetadata.xml file from the ADFS server that users will be authenticating against (we'll call it IP) in the browser.  By default the location will be https://myIpAdfsServer/FederationMetadata/2007-06/FederationMetadata.xml.  If you get an untrusted certificate error in the browser you'll need to add the root authority certificate for the IP ADFS server's SSL to your trusted root authorities store.  NOTE:  This assumes that you have the same root authority certificate for both the SSL access to the IP ADFS web server and the IP ADFS token signing certificate.  If they are not the same then you need to add the root certificate authority for BOTH to the local RP ADFS server's certificate store.  To do that:
   1. Click through to view the web site, which should show the Xml file.
   2. Click on the View Certificates icon so you can see the SSL certificate that was used.
   3. Click on the Certificate Path tab.
   4. Double-click on the top certificate in the chain - this is the root authority certificate.
   5. Click on the Details tab.
   6. Click on the Copy to File... button and save the certificate in CER format to the local disk.  You can now close out all of the certificate dialogs and browser.
   7. Open up the Certificates MMC; if you don't have a shortcut for this then just start the MMC from the Run menu, Add snap-ins, and add the Certificates snap-in for the Computer (local).
   8. Expand the Trusted Root Certification Authorities node, right-click on the Certificates node, and choose the Import menu.  Follow the wizard to import the root authority .CER file you exported above.
   9.  
2. Open up the AD FS 2.0 Management application.
3. Expand the Trust Relationships node, then right-click on the Claim Provider Trusts node and select Add Claims Provider Trust...
4. Click the Start button to begin the wizard.
5. Leave the default option selected to Import data about the claims provider published online or on a local network, and in the edit box put in the address to the FederationMetadata.xml file (https://myIpAdfsServer/FederationMetadata/2007-06/FederationMetadata.xml by default) then click the Next button.  If your root authority certificate is correctly installed and the name can be resolved, then the wizard will continue to the next step.  If not, you have troubleshooting to do.
6. Provide a Display Name and optionally Notes, then click the Next button.

More Here

Courtesy:http://blogs.technet.com/b/speschka/archive/2010/11/24/configuring-adfs-trusts-for-multiple-identity-providers-with-sharepoint-2010.aspx

Salesforce.com Single Sign On using ADFS v2

This is the universal identity problem – too many user accounts for the same person.  As such, one of my internal goals here is to simplify identity at ObjectSharp.
While working on another internal project with Salesforce i got to thinking about how it manages users.  It turns out Salesforce allows you to set it up as a SAML relying party.  ADFS v2 supports being a SAML IdP.  Theoretically we have both sides of the puzzle, but how does it work?
Well, first things first.  I checked out the security section of the configuration portal:

There was a Single Sign-On section, so I followed that and was given a pretty simple screen:

There isn’t much here to setup.  Going down the options, here is what I came up with:
SAML Version
I know from previous experience that ADFS supports version 2 of the SAML Protocol.

Issuer
What is the URI of the IdP, which in this case is going to be ADFS?  Within the ADFS MMC snap-in, if you right click the Service node you can access the properties:



In the properties dialog there is a textbox allowing you to change the Federation Service Identifier:

We want that URI.
Within Salesforce we set the Issuer to the identifier URI.
Identity Provider Certificate
Salesforce can’t just go and accept any token.  It needs to only be able to accept a token from my organization.  Therefore I upload the public key used to sign my tokens from ADFS.  You can access that token by going to ADFS and selecting the Certificates node:

Once in there you can select the signing certificate:

Just export the certificate and upload to Salesforce.
Custom Error URL
If the login fails for some reason, what URL should it go to?  If you leave it blank, it redirects to a generic Salesforce error page.
SAML User ID Type
This option is asking what information we are giving to Salesforce, so it can correlate that information to one of their internal ID’s.  Since for this demo I was just using my email address, I will leave it with Assertion contains User’s salesforce.com username.
SAML User ID Location
This option is asking where the above ID is located within the SAML token.  By default it will accept the nameidentifier but I don’t really want to pass my email as a name so I will select user ID is in an Attribute element.
Now I have to specify what claim type the email address is.  In this case I will go with the default for ADFS, which is http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress.
On to Active Directory Federation Services
We are about half way done.  Now we just need to tell ADFS about Salesforce.  It’s surprisingly simple.
Once you’ve saved the Salesforce settings, you are given a button to download the metadata:

Selecting that will let you download an XML document containing metadata about Salesforce as a relying party.
Telling ADFS about a relying party is pretty straightforward, and you can find the detailed steps in a previous post I wrote about halfway through the article.
Once you’ve added the relying party, all you need to do is create a rule that returns the user’s email address as the above claim type:

More Here

Courtesy:http://blogs.objectsharp.com/cs/blogs/steve/archive/2011/02/14/salesforce-com-single-sign-on-using-adfs-v2.aspx

Step-by-Step Guide: Exposing OWA 2010 with AD FS 2.0 to other organizations

Through the possible support for both an initial Claim-based Authentication (and the WS-Federation protocol), followed by a controlled protocol transition to Kerberos, through the use of Microsoft Windows Identity Foundation (WIF) 1.0, Microsoft Outlook Web Access (OWA) 2010 allows interoperability with major IDA market solutions. Through its support for the WS-Federation protocol among other OASIS standards, Microsoft Active Directory Federation Services 2.0 (AD FS 2.0) provides claims-based, cross-domain Web Single Sign-On (SSO) interoperability with non-Microsoft federation solutions.

Building on existing documentation, this step-by-step guide walks you through the setup of a basic lab deployment of AD FS 2.0 and OWA 2010 that exposes the OWA 2010 Web resource for cross-product, browser-based, federated collaboration. This document is intended for information technology (IT) professionals, and system architects who are interested in understanding the basic modes of interoperability between AD FS 2.0 and OWA 2010, and who want to create a lab environment for that purpose.

More Here

Courtesy:http://blogs.technet.com/b/rhalbheer/archive/2011/01/17/step-by-step-guide-exposing-owa-2010-with-ad-fs-2-0-to-other-organizations.aspx

Integrate DNN with ADFS without writing a new Authentication Provider

The partner organization already had ADFS setup. The goal was to have the partner organization authenticate the user and then have DNN automatically recognize the user, not having to enter any more credentials. From there we wanted to manage the groups and permissions through the regular DNN portal.
I was initially under the misconception that I could not use the current DNNMembershipProvider and I would have to create a whole new Authentication Provider and collect the credentials and pass them to my partner organization.



What I have figured out is that you CAN use the existing DNNMembership provider, but you have to create the user before the request gets to the DNNMembership provider using the information provided by ADFS.


Note: This method is a straight pass-through from ADFS to DNN. No measures are taken to authenticate the user or to check any of the inputs from ADFS.


As an aside, this method works not only with ADFS but also any other external 3rd-party Authentication method that sends user information in headers or cookies. Change the context_AuthenticateRequest method to suit your requirements.


Here are the pre-conditions to this article. I expect:



* Your partner organization has ADFS up and running
* You have your ADFS proxy up and running and it talks to the partner organization.
* ADFS Web Agent is installed on the server you are running.


Let’s get started.
HTTPModule


What you have to do is create an HTTPModule that will intercept the AuthorizeRequest events before DNN does. An over-simplified definition of an HTTPModule is, it is a piece of code that runs before any page gets hit. You can listen for a lot of different events. For more information, click here.


To create the HTTPModule you will need to:


* Open Visual Studio and create a new class library.
* Create a new class and copy the code attached to this blog.
*
Add References to the following DLLs
o DotNetNuke
o System.Web
o System.Web.Security.SingleSignOn
o System.Web.Security.SingleSignOn.ClaimsTransform
o System.Web.Security.SingleSignOn.Permissions
* Compile the solution
* The DLL that is created will need to be placed in the bin directory of your website.
* Make changes to your web.config (explained in a later section).


I will walk through a bit of the code. Here is the first snippet of code. We start listening for the AuthenticateRequest event. All other events pass through untouched.
view source
print?
1 public void Init(HttpApplication context)
2 {
3 //Start listening for each authentication request
4 context.AuthenticateRequest += new EventHandler(context_AuthenticateRequest);
5 }


Now, what do we do when this event is fired off? To shorten the namespace I added the statement
view source
print?
1 using SSO = System.Web.Security.SingleSignOn;


First off, we need to get the information that ADFS has sent us by casting the User.Identity into the ADFS object SingleSignOnIdentity.
view source
print?
1 public void context_AuthenticateRequest(object sender, EventArgs e)
2 {
3 HttpApplication app = (HttpApplication)sender;
4 //By the time the request gets to here, it should have been authenticated
5 //against ADFS.
6 SSO.SingleSignOnIdentity id = (SSO.SingleSignOnIdentity)app.User.Identity;


At this point you will have access to the user’s Identity and any claims coming from the ADFS server. You can access them through id.SecurityPropertyCollection. You can use them to populate the new user account. You can iterate through the claims with the following code
view source
print?
1 foreach(SecurityProperty sp in id.SecurityPropertyCollection)
2 {
3 Console.WriteLine(sp.Name);
4 Console.WriteLine(sp.Value);
5 }


Next, we check to see if the use already exists in the database by using the DNN API function GetUserByName. If it doesn’t, then the user is created by the standard DNN API function CreateUser and logged in. If the user does exist already then we log them in automatically. The user will automatically be added to the Registered Users and Subscribers security groups.
view source
print?
01 //'See if user exists in DNN Portal user DB
02 UserInfo objUserInfo = UserController.GetUserByName(currentPortal.PortalId, id.Name);
03 //' user does exist - try to create on the fly
04 if (objUserInfo == null)
05 {
06 objUserInfo = new UserInfo();
07 objUserInfo.DisplayName = id.Name;
08 objUserInfo.FirstName = id.Name;
09 objUserInfo.LastName = id.Name;
10 objUserInfo.Username = id.Name;
11 objUserInfo.Membership.Password = "AReallyStrongPassword";
12 objUserInfo.PortalID = currentPortal.PortalId;
13 objUserInfo.Email = id.Name;
14 UserCreateStatus objUserCreateStatus = UserController.CreateUser(ref objUserInfo);
15 //See if the user was added successfully
16 if (objUserCreateStatus == UserCreateStatus.Success)
17 {
18 //We have created them successfully, so let them into the site
19 LetsLogUserIn(objUserInfo);
20 }
21 else
22 {
23 //This will send the error to the error log, but the user will experience an infinite loop
24 throw new Exception("User not created successfully: " + objUserInfo.Username + "- " + objUserCreateStatus.ToString());
25 }


Here is the LetsLogUserIn function:
view source
print?
01 private void LetsLogUserIn(UserInfo objUserInfo)
02 {
03 try
04 {
05 //Get the current portal
06 PortalSettings currentPortal = PortalController.GetCurrentPortalSettings();
07 //set the language to the default language of the portal
08 Localization.SetLanguage(currentPortal.DefaultLanguage);
09 //Log the user in
10 UserController.UserLogin(currentPortal.PortalId,
11 objUserInfo,
12 currentPortal.PortalName,
13 HttpContext.Current.Request.UserHostAddress,
14 false);
15 }
16 catch(Exception ex)
17 {
18 Exceptions.LogException(ex);
19 }
20 }
Web.Config


We need to make several changes to the web.config. First we need to make the changes necessary for ADFS and then we need to make changes for our HTTPModule.


The ADFS changes are the standard web.config changes you would do for any ADFS claims-aware site. You first need to add the section groups to your web.config.
view source
print?
1
2

3


Then you need to add the actual section. The needs to be EXACTLY what is put into ADFS. Remember, this URL needs to have a / at the end to prevent ADFS from posting to a directory listing. The element needs to be changed to reflect the name of your server.
view source
print?
01
02 …
03
04
05 55
06
07 https://your_application/
08
09 https://fs-server/adfs/fs/federationserverservice.asmx
10
11 …
12


If you would like to have logging (and who doesn’t like loggingJ) you will need to add the following section at the end of your web.config

More Here

Courtesy:http://binnington.wordpress.com/

Access OWA with ADFS

One of the biggest advantages of using ADFS for your web applications (or any federated identity product for that matter) is that you can take advantage of the claims being passed to the application in the token. This data can be used by the application for making decisions about what the user will see – in other words, authorization. Or that identity data could be used for user personalization – such as displaying the text “Welcome, Ken”.

But what if your application doesn’t support claims? Do you need to rewrite it? In some cases, the answer is no – and what I’m talking about here today is one of those cases. You see, it is possible to use ADFS on applications that aren’t claims-aware, and what better to illustrate that on than Outlook Web App. In this post, I’m going to show you how to enable ADFS v2 for logging on to Outlook Web App in Exchange Server 2010.

The Mechanics of How This Works

Before we get started, let me explain a little bit about how this works. Outlook Web App is just like any other ASP.Net application – it uses IIS for hosting the site, which means that IIS also handles authentication for the web app.
Now, typically, applications that are claims aware use Windows Identity Foundation (WIF). WIF is the API that does all of the token-handling things that the application needs to happen. If I want to use ADFS and claims-based access in my application, I would use WIF as a fundamental component of that app. WIF would do a lot of the heavy lifting so my app doesn’t have to. For example, WIF would take care of receiving the token from ADFS, verifying that it’s legitimate, and even taking the claims out of it and making them consumable by my application.

WIF uses an HTTP module that listens for unauthenticated requests to the application and then takes over. For example, if I access an application without having logged in already, WIF will step in and take care of redirecting me to the ADFS server that it trusts – whom I might use for authentication. We add this HTTP module to an application by putting it in the app’s web.config file. Easy enough.
So what happens after I’m authenticated and my federated identity token is returned to the app? Typically, the token would be validated and parsed so that the claims can be used. However, let’s say that I’m using an app like OWA. OWA doesn’t know anything about claims and tokens, so if I gave it an ADFS token, it wouldn’t know what to do with it.
So what can we do? In older versions of ADFS (v1), there was an agent that you could install on the web server called the NT Token agent. This agent would sit on the server as an ISAPI filter, and after the token is passed to the server, it would map it to an Active Directory account and create an NT token for the user. This effectively turned an ADFS token into an NT token. This way, the application did not require claims – any old app could use ADFS for authentication. The only requirement was that an account has to exist in Active Directory for the user.
The NT Token agent got canned with ADFS v1 and is no longer available in ADFS v2. Some people found this disappointing, but one thing that many people missed is that we now have something even better. When you install WIF on a server, it installs a new Windows service that is Disabled by default. This service is called the Claims to Windows Token Service – or C2WTS. This service effectively does the same thing as the NT Token agent used to do – it turns an ADFS token into a Windows token. However, this time it doesn’t use an NT token – rather, it uses Kerberos Constrained Delegation (KCD) to request a Kerberos ticket on behalf of the identity specified in the UPN claim of the token. The target scenario of this capability is being able to use Kerberos delegation from a claims-based web app to a back-end system such as SQL Server.
Now, if we enable the C2WTS service, it basically steps in when a token is received, gets a Kerberos ticket, and passes it to the app instead. Since OWA is an ASP.Net application, and since it can use Windows Integrated Authentication, there is no reason why we should not be able to configure this in OWA.

Configuring OWA for ADFS

At a high level, here are the things that we are going to do to federate OWA with ADFS:

• Make sure OWA works fine without ADFS first
• Install WIF on the Exchange Client Access Server
• Configure the OWA web.config file to use the WS-Federation Authentication Module supplied by WIF
• Enable and configure the Claims to Windows Token Service
• Configure the Relying Party trust in ADFS

Step 1: Make Sure that OWA is Working Without ADFS

This may be common sense, but it’s a good idea to make sure that OWA is working normally before getting started. In this example, I’ve installed Exchange 2010 on a server called CONTOSO-EX1 and URL for OWA is mail.contoso.com. As you can see, when I browse to OWA, I’m prompted for my Active Directory credentials in Exchange’s Forms Based Authentication page.

Step 2: Install Windows Identity Foundation

The next thing to do is to install Windows Identity Foundation on the Client Access Server. You can download WIF from here. After you install WIF, you should see a new service on the Client Access Server called the Claims to Windows Token Service. This service is not enabled by default. This is what we will be using to turn our SAML token into a Kerberos ticket.

Step 3: Install the Windows Identity Foundation SDK

You installed WIF in the previous step, so you may be wondering why you need the SDK. There is one tool included in the SDK that you need – FedUtil.exe. If you have the SDK installed somewhere else, you can just grab that tool from the SDK and copy it to the Client Access Server. Otherwise, you can download the WIF SDK from here and install it on the Client Access Server. After you install the WIF SDK, you should have FedUtil in the “c:\Program Files (x86)\Windows Identity Foundation SDK\v3.5\” folder.

Step 4: Configure OWA

Now, you need to run the utility called FedUtil.exe. This tool will update the web.config file for OWA and configure it to trust the ADFS server. You will find the tool on the Client Access Server under “c:\Program Files (x86)\Windows Identity Foundation SDK\v3.5\”. When you run FedUtil.exe, you will get the following dialog:

For the Application Configuration Location field, enter the path to the OWA web.config, which will be “c:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\web.config” if you are using a default installation of Exchange.
In the Application URI field, enter the URL for OWA – https://mail.contoso.com/owa in my example.
After you click Next, you will need to enter the URL of your ADFS server so FedUtil can grab the federation metadata file. You can just type in the DNS name of the ADFS service, and FedUtil will fill in the rest.

You can walk through the rest of wizard, leaving everything else at the default value. If you were to browse to OWA now, you would see that the authentication module is working, and it will redirect you to the ADFS server instead of presenting you with the OWA forms-based logon page. You can see from the following screen capture that I’m being asked to logon at sts.contoso.com (the ADFS server) instead of mail.contoso.com (the Exchange server).

However, we don’t have the ADFS side of the trust configured yet. And even if we did, OWA would get the SAML token back from ADFS and not know what to do with it because we didn’t configure C2WTS yet.
But before we do, there is one other thing we have to do in OWA. We need to turn off Forms Based Auth. In the Exchange Management Console, open your OWA authentication settings dialog and tell OWA to use IIS. You can get to this dialog by choosing Server Configuration > Client Access, and then select the OWA virtual directory in the bottom pane of the Exchange Management Console.

Just choose Properties to bring up the configuration dialog. Go to the Authentication tab and set the option to “Use one or more standard authentication methods”.

Then, you’ll need to go into IIS on the Client Access server and enable Anonymous Authentication on the OWA virtual directory. To do this, open IIS Manager, browse to the OWA virtual directory, and double-click on the Authentication icon.

Set the Anonymous Authentication setting to Enabled. After you are done, make sure that you run iisreset.

Step 5: Configure C2WTS

There are a few things that you need to do to configure C2WTS. The first is to configure the service and turn it on. To configure it, you will need to allow the Exchange server to use it by modifying C2WTS’es configuration file. You will find this file in “C:\Program Files\Windows Identity Foundation\v3.5\c2wtshost.exe.config”. Open the file in Notepad, and uncomment the following line:

Save the file, and then set the C2WTS service to Automatic and start it up.

The second thing is that you need to go back into the OWA web.config file and tell WIF to use C2WTS to turn the SAML token into a Windows token instead of giving the SAML token back to OWA directly. So go back into OWA’s web.config file, scroll all the way down near the bottom, and add the following text into the Microsoft.IdentityModel element under the Service element:

 
   
 

Two main things that we’re adding here are the parameters mapToWindows and useWindowsTokenService. These two things enable OWA to use C2WTS. Here’s a screen capture of the modified file after the text was added:

Step 6: Set up Relying Party Trust in ADFS

The last step is to add the Relying Party side of the trust in ADFS. You can do this using the standard Add Relying Party Trust wizard in ADFS and using OWA’s Federation Metadata file, which was created in step 4 when we ran FedUtil. In the RP trust wizard, enter the URL for OWA. The wizard will take care of finding the Federation Metadata file, so you don’t have to specify the full path to it.

You can just specify the default values for the rest of the wizard. After you are done, you may get the Claims Rules dialog for the trust. If you do, you can just close it for now.
In order for C2WTS to work, you need to pass a UPN claim in the SAML token. C2WTS uses the UPN claim to look up the user that you want to create the Windows Token for in Active Directory. So, now we need to configure a couple of claim rules to get the UPN out of Active Directory and into the SAML token passed to OWA.
First, we need to make sure that the UPN claims is coming in from Active Directory.

1. In ADFS, go to your Claims Provider Trusts, select the Active Directory claims provider, and choose Edit Claim Rules.
2. In the Edit Claim Rules dialog, click the Add Rule button.
3. In the rule wizard, choose the “Send LDAP Attributes as Claims” template
4. In the rule configuration screen, select the Active Directory attribute store and choose to send LDAP attribute User-Principle-Name in the Outgoing Claim Type labeled UPN, as shown in the following screen capture.

The second thing we need to do is to configure ADFS to pass the UPN claim to OWA.

1. In the ADFS Management Tool, go to the Relying Party Trust that you created for OWA and choose to edit the claim rules there.
2. In the Issuance Transform Rules tab, click the Add Rule button.
3. In the rule wizard, use the template called Pass Through or Filter an Incoming Claim
4. In the Incoming Claim Type field, select the UPN claim and choose “Pass through all claim values”, as shown in the following screen capture:

Trying it Out

Now that everything is configured, we can try it out. Before you do, make sure that the account you are testing has a valid mailbox in Exchange and also has the UPN attribute populated in Active Directory.
Using my client, I will browse to https://mail.contoso.com, and I am re-directed to ADFS to log in. I’ll log in with my user’s credentials:

And voila… I’m now logged into OWA via ADFS -

More Here

Courtesy:http://olegsoroka.wordpress.com/2010/12/13/access-owa-with-adfs/