Interesting Code Exception–UnwillingToPerform

I have recently been busy putting the finishing touches on a new web application for a client in Indiana.  During the course of the project, we discovered that we needed to write a custom membership provider that would use secure LDAP to authenticate users (the ActiveDirectoryMembershipProvider does not, surprisingly, support the client's environment setup). 

While developing the basic provider was relatively easy to complete (and used an Oracle LDAP provider we built previously), we ran into a series of challenges.  One challenge is now a support incident at Microsoft (more on that in a later blog).

However, during one of the debugging sessions, we noticed an "unspecified operation error occurred" exception being thrown.  Digging down, we discovered the reason code: "unwilling to perform"

I have never thought about putting that kind of reason in my code, but if Microsoft can do it, perhaps it's O.K.

Oracle Internet Directory Membership Provider (LDAP) for SharePoint

A while back, I posted an article on how to create a SharePoint membership provider for Oracle’s Internet Directory (LDAP).   The post continues to be a relatively popular post and more than a few folks have asked for the source directly.

While I’ve generally tried to e-mail the membership class directly to anyone who requests it, simply posting it to the Consejo blog is probably easier on everyone.

Here’s a TXT version of the C# class.  While I’ve refactored subsequent versions of this class a few times, this version is still pretty raw, but functional (read: it’s a good start if you have nothing).  In this version, I used Kellerman’s Encryption Library to handle the MD4/MD5 hash format used by my client’s directory; interestingly they used one method for their test environment and one for their production environment.   While the Kellerman library is quite affordable (and easy to use), there is an open source alternative on CodePlex called .NET Crypto (Devv.Core.Crypto) as well as Microsoft’s Enterprise library, which include cryptography functions.

Other notes on the code:

• If you have a MOSS implementation, you don’t need this class.  Microsoft provides an generic LDAP provider with the full server product.  This was written for those who only have WSS and need something custom.
• The original requirements for this class were for creating a single sign-on environment between an Oracle Portal and SharePoint (sign on to the Oracle portal and get straight in to SharePoint without authentication).  As such, I didn’t write any code to handle password changes, resets or other management functions, since those would all be handled by Oracle’s product interfaces.
• I’ve only overloaded the bare minimum necessary for the membership provider to work with SharePoint (see above bullet).
• The lookup function for users requires exact matches.  In hindsight, I could have implemented the query a bit better to improve operation with the People Picker component in SharePoint; I didn’t, but hopefully you will and share it with the rest of us…
• This was originally written for WSS v3.0, but there’s no reason, with potentially minor changes, it couldn’t work for SharePoint Foundation (2010).  If you get it to work in a 2010 environment, I’d love to see the implementation and hear your experiences.

 

Click HERE to get a copy of the provider class.

SharePoint and Oracle Internet Directory (LDAP)

[UPDATE 6 SEPT 2010] The code has been posted on a new article about connecting SharePoint to Oracle LDAP

I have a client who recently wanted to leverage their Oracle Internet Directory server to authenticate users in SharePoint.  Since OID is LDAP compliant, I figured I could just use the generic LDAP provider with SharePoint.  Turns out, that provider is only supplied with MOSS and my client was using WSS.  So, off to Visual Studio to create a custom membership provider I went. 

I've seen a number of posts regarding the creation of custom membership providers for non-Microsoft directory sources like SunOne and OID.  However, I never saw any code samples (most folks didn't seem to be able to get it to work).  While other posts on custom membership providers tended to rehash the same material on SQL Membership.  As it turns out, it's pretty straight forward, as long as you have all of the right connection information (and understand the schema of the directory).  I would be happy to post the code if anyone is interested.  Short of that, here are some of the discoveries I've made:

1. You can use the standard System.DirectoryServices.Protocols.LdapConnection class to connect to OID.  Here's the generic code I used:
   

   LdapDirectoryIdentifier _identifier = new LdapDirectoryIdentifier(ldapServerName, portNumber);
   connection = new System.DirectoryServices.Protocols.LdapConnection(_identifier);

2. You need to override the Initialize member of the base membership class to supply the various connection settings you'll need.  There's a NameValue collection that's passed to this member built from the properties on the provider information you have to supply in Web.Config.  In my case, I limited my settings to LDAP server address (name or IP address), the LDAP port (originally my client suggested they used a non-standard port), Application Name (a property you must override when developing a custom membership provider) and LDAP domain (e.g. dc=com,  dc=customer).   The MOSS supplied provider is a bit more flexible, but I didn't particularly need all of that flexibility (read "complexity").
3. I had to add the same provider information to Central Administration as I did for my SharePoint site.  I didn't change the authentication method on Central Admin, but without adding the provider, I could not get the people picker (in my SharePoint site) to resolve the user IDs from OID.  Once I added the provider all worked well.  In fact, in some cases, it seems that Central Admin "knows" about the user before the SharePoint application.
4. You have to overload the following members in the base membership provider in order for it to work with SharePoint
   1. ValidateUser (the member that actually ensures the user is who they say they are)
   2. GetUser (both versions)
   3. GetUserNameByEMail
   4. FindUsersByName
   5. GetAllUsers
      
      An article published on MSDN defines the minimum interfaces: http://msdn.microsoft.com/en-us/library/bb975135.aspx#MOSSFBAPart2_DevelopingCustom
5. You don't necessarily have to authenticate with the directory to exercise most of the members above, with the exception of ValidateUser.  In my case, my client's OID implementation enabled anonymous access.
6. The act of "binding" to the LDAP directory validated the user.  That said, this only worked for users in the directory.  If I passed a user that did exist, but provided the wrong password, the validation failed as expected.  If, however, I passed a non-existent user to the directory (regardless of the combination of user ID and password), the Bind() method did not return any errors and my "authentication" worked.    I'm not sure if I've missed something or if this is unique to LDAP, but it was a strange behavior.  During my development I used a tool called LDAP Admin (http://ldapadmin.sourceforge.net/).  The tool was invaluable for validating connection information and user data.  It also, however, suffered the same fate as my code -if I tried to authenticate a user that didn't exist, the connection would be successful.  Weird.
7. My client also wanted to use a single sign-on service provided by OID.  The service is quite flexible, supporting three different methods for supplying credentials to target applications - GET, POST and BASIC..  Unfortunately, since we configured the site with a custom membership provider, the only options were either GET or POST.  We chose post.  Unfortunately, the standard login page doesn't seem to want to allow a post from another page (although I didn't spend a long time to work it out).  I ended up constructing a basic page that took in form properties and then used the Membership class to authenticate the user and redirect them back to the SharePoint site.

Ultimately, the new provider works well and the SharePoint site is integrated with the SSO server.  User's who have access to my client's Oracle Portal can seamlessly access their SharePoint site as well  -- all without having to authenticate a second time.  And, because both web sites use the same LDAP, there's not need to synchronize user IDs and passwords.

Again, if you're interested in the code, just drop me a line; if I get enough requests, I'll post the code directly.

[UPDATE 6 SEPT 2010] The code has been posted on a new article about connecting SharePoint to Oracle LDAP