Inconvenient configuration of Forms-Based Authentication in SharePoint 2010

For an extranet we aim to utilize Forms-Based Authentication to authenticate external users. In SharePoint 2010 this means that you have to apply the Claims-Based authentication model. And next set up the SharePoint webapplication configuration for the Membership provider that will be used for FBA. This is where things can be a little confusing. In fact you have to configure FBA membership on 3 different locations, and it is essential that all 3 are in sync:

1. In Central Admin

Configure Web Application \ Authentication Providers; here you specify the name of the Membership- and RoleProviders used in FBA context within the web application

2. Security Token context

In the SharePoint 2010 service applications architecture, membership handling is delegated to the SecurityToken service application. This is a major difference wrt SharePoint 2007 architecture, in which the individual webapplication process themselves handle the membership handling. Direct consequence for configuration is that you need to specify in the web.config of the SecurityToken service application all the membershipproviders and roleproviders that are used in the SharePoint farm.

The SecurityToken service application directory is located at: 14hive\WebServices\SecurityToken

3. Webapplication context

Finally, despite that membership handling is within SharePoint 2010 done via the independent SecurityToken service application; you may still need to add the membershipprovider to the web.config of the individual webapplication. This is required in case you want to be able to use the standard PeoplePicker for selecting credentials via the FBA membershipprovider. Besides adding the ‘membershipprovider’ node, you then also have to set the peoplepicker directing to that membership provider.

What if the 3 locations are not in sync? I evaluated the different inconsistent configurations:

1. Name entered in Central Admin does not match with name in SecureToken’s web.config

In this case, SharePoint Identity handling cannot get an handle to the configured MembershipProvider. When someone tries to log in via Forms-Based Authentication, SharePoint Identity handling will report the displayed exception.

Note, to have the 'Cannot get Membership Provider' exception details displayed you already need to make a change to the default settings within SecurityToken web.config. Namely set attribute includeExceptionDetailInFaults of ServiceDebug to true. Without this, only a general error is displayed: The server was unable to process the request due to an internal error

2. Missing MembershipProvider in Central Admin

Well, you cannot actually forget to fill them in if you selected ‘Enable Forms Based Authentication’. But you could per accident forget to select that option.

The result of this is more a functional error: the forms-based authentication is now missing as option to logon to the web application.

3. Missing or different named MembershipProvider in web application’s web.config

In this case you can still logon to the webapplication: either via Windows Authentication or via FBA. See above, membership is namely handled by SecurityToken service application, and not by the webapplication self. This can be a bit confusing at first. The result of the configuration error is noticed within the application self, when you try to search credentials from the FBA-Membership provider via the PeoplePicker. Strange enough the PeoplePicker is aware of the configured FBA-membership, but apparently cannot include it in it’s search space.

4. Mismatch PeoplePicker (incorrect) versus named MembershipProvider in webapplication’s web.config

In this case strangely enough, PeoplePicker is able to use the Membership provider, that is if it is consistently named wrt SecurityToken web.config (otherwise issue 1).

At first I could not detect any PeoplePicker malfunction as result of this configuration mismatch. I could still find all credentials in the membershipprovider, also via wildcarding.

Only when I on purpose sabotaged the wildcarding, I could see the effect.

So it appears that for wildcard search the ‘%’ is already somewhere set as default for all Membership providers; and that you only have to override this in case your Membership provider uses a different wildcard-pattern.

Personally, I find it better to always be explicit; and thus also explicitly specify ‘%’ as wildcharacter for each Membership provider that is valid for your application. But it is optional, and others might differ with me on this…

Claims-based SSO with SAML 2.0

On SAP Community Network the presentation Next Generation SSO for SAP Applications with SAML 2.0 is published containing an overview about authentication, single sign-on (SSO), and identity federation for SAP centric applications. Combined with the recent release of Microsoft's Claims-Based identity platform (Windows Identity Foundation, formerly known as Geneva), and IBM enabling Identity Federation via its WebSphere Application Server (Identity federation using SAML and WebSphere software); 3 of the largest software companies are taking significant steps on this requisite for the interoperability puzzle. Of the remaining other large software companies, Oracle has an handle to the OpenSSO product via the SUN acquisition. But doubt rises about the willingness and commitment of Oracle to OpenSSO - a first sign of this is demonstrated by some broken links to OpenSSO information. From the Google camp I yet miss notion of their plans and products on the Claims-Based Identity subject. I expect that it will either originate from the Open Source community, or donate to it. Who knows, perhaps Google (allthough IBM is a more likely candidate) would be the ideal new founder for OpenSSO...

Interesting sessions on SAP/MS interop at the SAP TechEd's 2009

In the coming weeks the SAP TechEd 2009 will be held, at various locations worldwide. The series starts in Phoenix (USA), following Vienna (EMEA market), Shanghai (China) and ends in Bangalore (India).

The SAP TechEd is filled with lots of interesting sessions, divided within 7 tracks. From the perspective of SAP / MS platforms interoperability, the tracks SOA Middleware, Security and Identity Management and Custom Development appear the most interesting ones. And within them especially the following sessions

• Duet Best Practices: Fast-Track Your Duet 1.5 Operations with Duet Admin Tools
• Customizing Alloy: Exposing SAP Workflows to Lotus Notes
• Interoperability Between SAP NetWeaver Portal and Microsoft SharePoint Technologies
• Integrating SAP with Office 2010 and SharePoint 2010
• Creating Online and Offline Form Processing Scenarios with Adobe Forms and Web Dynpro for ABAP
• Architecture Guidelines for Composite Applications
• Standards-Based Interoperability between SAP NetWeaver PI and Microsoft .NET
• SAP NetWeaver Process Integration 7.1: SAML Implementation
• Enterprise Services Repository in Complex Customer Landscapes
• SAP and Microsoft: Interoperability and Beyond
• Tactical SOA Governance in SAP Environment
• Business Process Management and Security – Inextricably Intertwined
• Service-Based Single Sign-On in an SAP and Microsoft Combined Environment

I'm pleasently surprised by the attention SAP gives to the field of platforms-interoperability in general, and that of SAP/Microsoft in particular. Although I self are not able to join this conference (I'm instead scheduled for the soon coming Microsoft SharePoint Conference 2009), a TopForce colleague will attend. So I hope and expect to receive the details via him.

Tags: SAP NetWeaver Microsoft SharePoint integration interoperability SSO

Studying Single Sign-On approaches for SAP and Microsoft

In todays typical heterogenous enterprise IT environment, an end-user works with multiple IT products and applications which have varying authentication mechanisms. In such situations a well-desired functionality is to have Single Sign-On (SSO) enabled. The last days I (re)did some research into this area.

The concept of SSO has a direct and narrow relationship with Identity Management. At the area of IM several interesting new developments are lately either done or announced. Sun (almost Oracle nowadays) has its OpenSSO Enterprise flagship, Microsoft recently gave indepth insight into it's forthcoming "Geneva" initiative. Both technologies/products are representatives of the so-called Claims-Based Identity model. And the beauty is that both IM technologies conform to the Security Assertion Markup Language (SAML) federation standard as a basis for interoperability and ease of collaboration. In a joint co-operation, Sun and Microsoft have produced a whitepaper that discusses the interoperability possibilities between the 2 Identity Federation approaches, and gives answers on typical questions. Microsoft and Sun also have some working showcases to demonstrate the interoperability.

For the specific area of SSO in an heterogenous SAP / Microsoft IT landscape, the SAP-Microsoft alliance has an excellent overview whitepaper available: Unleash the Power of Single Sign-On with Microsoft and SAP. A sidemark is that this document appeared in september 2007. Later developments as the mentioned OpenSSO and "Geneva" are therefore not included. Still, to my opinion the whitepaper is not outdated, but simple no longer complete. The description and positioning of the included SSO approaches is still valid and useful. And you can easily complement yourself the 2007-temporal overview of SSO alternatives with the new technologies and products.

Tags: SAP NetWeaver Microsoft SharePoint integration interoperability SSO Identity Management IDM IAM SPNego OpenSSO