SSO to SharePoint 2010 through UAG when using two authentication schemas

發行項
11/15/2011

Hi everyone, this is Dror from the Forefront UAG product group.

One of our customers ran into an issue with their SharePoint deployment and we thought it is worth sharing with you all the ways that UAG can be leveraged.

Let’s assume a topology like this one:

In this case, two different categories of users gain access to the SharePoint farm via UAG: internal users (while outside of the company network), and partner users. Windows Integrated authentication is used in SharePoint for internal users, while form-based authentication is used for partner users. However, the SharePoint URL is the same for both types of users. As such, we have a case where SharePoint 2010 is configured with two authentication schemes for the same Intranet Zone.

Normally, in SharePoint 2010 in a scenario where you configure more than one authentication per zone, users are presented with a form where they need to choose which authentication method to use:

Till now everything is cool…

Most customers wish to have a single sign-on (SSO) experience for their users. That means that once users are logged in to UAG, they will not be prompted for credentials again. This is the SSO functionality that UAG offers. The question we faced in this specific case was: how can we achieve the same end-user experience of no additional prompts to the end-user, in this case where the “Multi-authentication selection” page is required by SharePoint?

There are 2 ways to handle this “Multi-authentication selection” page:

1. Auto-submit the page with a pre-defined selection – The UAG administrator can decide on the selected option by applying a custom setting. In this case, when the page sent by the SharePoint server is received by UAG, and before UAG sends it on its way to the client browser, UAG injects into the “Multi-authentication selection” page some code, in order to cause the page, as soon as it’s displayed on the user’s browser, to be automatically submitted with a predefined option, either Windows Authentication or Forms Authentication, without requiring any end-user interaction.

Here is a sample of this customization, using a custom AppWrap file, which shows the steps. Note that this example cannot be used ‘as is’ since all the values in the SEARCH and REPLACE fields need to be BASE64-encoded.

<APP_WRAP ver="3.0" id="RemoteAccess_HTTPS.xml">

<MANIPULATION_PER_APPLICATION>

<APPLICATION_TYPE>SharePoint14AAM</APPLICATION_TYPE>

<DATA_CHANGE>

<URL case_sensitive="false">.*/_login/default\.aspx.*</URL>

<SAR>

<REPLACE encoding="base64"><option selected="selected" value="Forms">Forms Authentication</option></REPLACE>

</SAR>

<SAR>

function FormLoginSubmit()

{

var o = document.getElementById('ctl00_PlaceHolderMain_ClaimsLogonSelector');

var evt = document.createEventObject();

o.fireEvent('onchange',evt);

o=null;

}

</SCRIPT>

var gSafeOnload = new Array();

function FormLoginOnload()

{

for (var i=0; i < gSafeOnload.length; i++)

{

gSafeOnload[i]();

}

if (window.onload) {

gSafeOnload[0] = window.onload;

gSafeOnload[gSafeOnload.length] = FormLoginSubmit;

window.onload = FormLoginOnload;

}

else

{

window.onload = FormLoginSubmit;

}

</SCRIPT>

</body></REPLACE>

</SAR>

</DATA_CHANGE>

</MANIPULATION_PER_APPLICATION>

</MANIPULATION>

</APP_WRAP>

2. Auto-submit the page with a selection based on a session (user) parameter – This is an extension of the first method, as shown above. Using this method, the selection between Windows or Forms authentication is not pre-defined and constant for all UAG sessions, and instead it can be dynamically set for each UAG session. The UAG administrator can set a parameter with one of two values, which UAG will later use to decide which authentication method to choose when submitting the “Multi-authentication selection” form. This parameter is stored within the context of the UAG session and it can be set by using the UAG customization mechanism. UAG makes its decision using the conditional AppWrap mechanism.

In the example below the Contoso administrator uses a custom ValidateSuccess.inc file to insert a parameter named AuthenticationMethodVar into the UAG session. In this file, VBScript code is used to check if the user’s UPN is part of the Contoso domain. If yes, the value of AuthenticationMethodVar is set to WINDOWS, otherwise it is set to FORM. In the custom AppWrap file we use this value to decide which of the authentication methods will be selected.

' Add a session variable based on user internal/external

MyUserUDomain = “contoso\”

if Left(Session("LeadUser"), Len(MyUserUDomain)) = MyUserUDomain then

SetSessionParam g_cookie, “AuthenticationMethodVar”, “FORM”

else

SetSessionParam g_cookie, “AuthenticationMethodVar”, “WINDOWS”

end if

<APP_WRAP ver="3.0" id="RemoteAccess_HTTPS.xml">

<MANIPULATION_PER_APPLICATION>

<APPLICATION_TYPE>SharePoint14AAM</APPLICATION_TYPE>

<DATA_CHANGE>

<URL case_sensitive="false">.*/_login/default\.aspx.*</URL>

<REPLACE encoding="base64"><option selected="selected" value="Windows">Internal User</option></REPLACE>

</SAR>

<REPLACE encoding="base64"><option selected="selected" value="Forms">Partner User</option></REPLACE>

</SAR>

<SAR>

function FormLoginSubmit()

{

var o = document.getElementById('ctl00_PlaceHolderMain_ClaimsLogonSelector');

var evt = document.createEventObject();

o.fireEvent('onchange',evt);

o=null;

}

</SCRIPT>

var gSafeOnload = new Array();

function FormLoginOnload()

{

for (var i=0; i < gSafeOnload.length; i++)

{

gSafeOnload[i]();

}

if (window.onload) {

gSafeOnload[0] = window.onload;

gSafeOnload[gSafeOnload.length] = FormLoginSubmit;

window.onload = FormLoginOnload;

}

else

{

window.onload = FormLoginSubmit;

}

</SCRIPT>

</body></REPLACE>

</SAR>

</DATA_CHANGE>

</MANIPULATION_PER_APPLICATION>

</MANIPULATION>

</APP_WRAP>

Once this form is submitted, the flow will continue according to the selection submitted back from the client browser (remember, the end-user has no say and no interaction with the form, as the selection is made on the end-user’s behalf by the UAG administrator, by using one of the two methods described above). For Windows Integrated authentication, the SharePoint server returns an HTTP 401 response to which UAG answers on behalf of the user. For FBA, the SharePoint server returns its authentication form, which UAG handles in its normal way of handling SSO to backend web sites that use FBA – UAG injects some content into that form, before sending it to the browser, then, once the browser receives it from UAG, it renders the page and immediately submits it back, without any user interaction (due to code injected by UAG) and SSO is completed.

Note that in order for both of these options to work, in the UAG Management console the authentication for the SharePoint application should be configured to Use SSO for Both (which means UAG should be ready to handle HTTP 401 responses, as well as the HTML form of the SharePoint server).

Author:

Dror Melovany, Software Development Engineer, Microsoft Forefront UAG

Comments

Anonymous
January 01, 2003
Why was Integrated Auth used for the Internal users when accessing from outside the internal network? Wouldn't it have made more sense to use FBA for all users coming in outside the internal network? Then you could have had a single auth mechanism on the Intranet zone and just use multiple membership/role providers. Or have I missed something here? And yes, I'm about to try and set up something similar.
Anonymous
January 01, 2003
Hello, Some interesting info here. We are in a similar situation at our university. WE have SharePoint as our Portal and have two auth systems AD (faculty and staff) and a custom LDAP via Shibboleth (students). We are looking to approach something similar. Would such a setup (Custom Claims in SharePoint and AD in SharePoint) work with UAG in the fashion you suggested above?
Anonymous
November 30, 2011
I have a very similar setup with the only difference is that the SharePoint FORMS auth source is a separate AD Forest that the partners live in. In my case I need UAG to know about two auth sources, ADForest1 (for employees and Windows integrated auth) and ADForest2 (for partners and Forms auth). My question is if I need to define both auth sources on the trunk or on the application. If so, how can I prevent UAG from presenting an auth prompt to select which auth source (ADForest1 or ADForest2) when the users go to the site. In our scenario, we plan on using the same URL or sharepoint AAM ofhttps://site.company.com for example. Thanks
Anonymous
January 13, 2012
The comment has been removed
Anonymous
September 11, 2012
What is the folder path to place ValidateSuccess.inc and RemoteAccess_HTTPS.xml files? Thanks
Anonymous
October 17, 2013
Hi, thanks for the great post, exactly what I am looking for. Unfortunately I have the same question as above from Chandra, where should we be putting the ValidateSuccess.inc and RemoteAcces_HTTPS.xml files?
Anonymous
October 21, 2013
The ValidateSuccess.inc is placed in here. The filename should be in the form of [trunkname][0 or 1] and then ValidateSuccess.inc Microsoft Forefront Unified Access GatewayvonInternalSiteincCustomUpdate For example, Share1ValidateSuccess.inc assuming Share is my trunk name and 1 is for SSL and 0 for non-SSL. The WhlFltAppWrap_HTTPS.xml is placed into here: Microsoft Forefront Unified Access GatewayvonConfWebSitesappsconfCustomUpdate The solution seems to work great.....for Internet Explorer. Unfortunately doesn't seem to work for Firefox, Chrome and Safari.
Anonymous
February 26, 2014
i want to directly login to sharepoint rather login to UAG portal.. is it possible?
in the backend it has to go through the UAG and route it to the internal site.

共用方式為

SSO to SharePoint 2010 through UAG when using two authentication schemas

Comments

其他資源