SharePoint and Coffee ... Perfect Together

It's not clear what implication the following recommendation from Amazon may have, but I suspect that Rob Bogue et. al. will be thrilled with the additional promotion. 

In fact, the recommendation is a split -- promotion of products based on what I just ordered (K-Cups for my new coffee maker) and products that fit my purchasing habits over the last few months.  However, the presentation of the two recommendations together made for a remarkable checkout process.

Take control of SharePoint Security

One challenge for companies implementing SharePoint is to figure out security. Keeping the model straight over time, as the SharePoint implementation matures, is even more of a challenge. SharePoint's ease of installation and high-level configuration can sometimes mask its underlying complexity, especially when dealing with more advanced scenarios like security.

Click here for the rest of the article on SearchWinIt.COM

Integrating existing applications with SharePoint Server 2007

It's likely that you are using Microsoft Office SharePoint Server 2007 in your organization. If not, there's probably a strong contingent within your organization lobbying to implement the technology.

Once you have SharePoint server, though, there's the inevitable challenge of integrating existing applications into the portal framework. So, this begs the question -- if you want to use SharePoint as your enterprise portal platform, how do you integrate applications that aren't "SharePoint-aware?"

 

Read the rest of the my new article on SearchWinIT.COM

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