Wednesday, September 10, 2008
Bridge SharePoint - User Profiles and User Profile Properties (part 1 of 2)
There is a constant need in SharePoint feature development to bridge SharePoint 2007 with other web applications. In order to create such a bridge, a variety of user information must be stored in the SharePoint database.
Warning: Do not tamper with the SharePoint database! No matter how tempting it is!
Although this might sound as simple as a small SQL application, tampering with SharePoint’s database could lead to disastrous results and even complete and irreversible server crashes, since many of SharePoint’s recovery features rely on the database being intact. “Feeding” information to SharePoint through its database is unadvisable and sometimes very hard to do, mainly due to the complex structure of the database.
Fortunately there is a built-in solution to this problem that is both simple and efficient: User Profiles and User Profile Properties.
In this post we will see how SharePoint’s user profiles and profile properties can help us do our job fast and easy without worrying about crashing the server or breaking more features than we create.
Let’s start with the storing information problem.
Many developers have already considered using Profile Properties as way to store the required data, but have given up on using them due to their limitations (limited validation, control, variety). Controlling the user’s input and making sure that the values are correct is essential in any bridge, and often auto-generated values based on that data are necessary. SharePoint can only do so much, and this is usually the main reason why developers avoid using the custom profile properties.
Solution: Manage information using the Microsoft.Office.Server.UserProfiles namespaces.
SharePoint Server 2007 stores user profiles in SQL Server, but the information can be imported from other data sources, such as:
· Active Directory
· Lightweight Directory Access Protocol directories (which is not Active Directory)
· Databases
· Enterprise applications (such as SAP or PeopleSoft) by defining a Business Data Catalog connection
· Web applications
· Custom SharePoint web services
· Standard .NET applications, etc.
The main classes are found in the Microsoft.Office.Server.UserProfiles namespaces. The assembly is Microsoft.Office.Server.dll found in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\ISAPI.
The main objects to handle information within the User Profile store are:
UserProfile
Allows you to access profile properties, the My Site, personalization links, and so on.
UserProfileManager
Gives access to a collection of UserProfile objects and allows you to create, edit, and retrieve user profile objects and properties from the user profile store.
UserProfileConfigManager
Manages the user profile configuration.
Note: In order to manage data in a custom user profile property, the property must be first created. You can use the following steps to create a profile property:
1. Start > Administrative Tools > SharePoint 3.0 Central Administrator
2. In the left panel, under Shared Services Administration, click SharedServices1
3. Click User Profiles and Properties
4. Under User Profile Properties, click Add Profile Property
5. Fill in the required data and click OK
Now that we know that SharePoint accepts data from external sources and that it stores individual user values in user profile properties, it’s time to put the two together and find out how to store user data in profile properties from external data sources. This is the topic for part two of this post: Getting/Storing user data from external sources.
Warning: Do not tamper with the SharePoint database! No matter how tempting it is!
Although this might sound as simple as a small SQL application, tampering with SharePoint’s database could lead to disastrous results and even complete and irreversible server crashes, since many of SharePoint’s recovery features rely on the database being intact. “Feeding” information to SharePoint through its database is unadvisable and sometimes very hard to do, mainly due to the complex structure of the database.
Fortunately there is a built-in solution to this problem that is both simple and efficient: User Profiles and User Profile Properties.
In this post we will see how SharePoint’s user profiles and profile properties can help us do our job fast and easy without worrying about crashing the server or breaking more features than we create.
Let’s start with the storing information problem.
Many developers have already considered using Profile Properties as way to store the required data, but have given up on using them due to their limitations (limited validation, control, variety). Controlling the user’s input and making sure that the values are correct is essential in any bridge, and often auto-generated values based on that data are necessary. SharePoint can only do so much, and this is usually the main reason why developers avoid using the custom profile properties.
Solution: Manage information using the Microsoft.Office.Server.UserProfiles namespaces.
SharePoint Server 2007 stores user profiles in SQL Server, but the information can be imported from other data sources, such as:
· Active Directory
· Lightweight Directory Access Protocol directories (which is not Active Directory)
· Databases
· Enterprise applications (such as SAP or PeopleSoft) by defining a Business Data Catalog connection
· Web applications
· Custom SharePoint web services
· Standard .NET applications, etc.
The main classes are found in the Microsoft.Office.Server.UserProfiles namespaces. The assembly is Microsoft.Office.Server.dll found in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\ISAPI.
The main objects to handle information within the User Profile store are:
UserProfile
Allows you to access profile properties, the My Site, personalization links, and so on.
UserProfileManager
Gives access to a collection of UserProfile objects and allows you to create, edit, and retrieve user profile objects and properties from the user profile store.
UserProfileConfigManager
Manages the user profile configuration.
Note: In order to manage data in a custom user profile property, the property must be first created. You can use the following steps to create a profile property:
1. Start > Administrative Tools > SharePoint 3.0 Central Administrator
2. In the left panel, under Shared Services Administration, click SharedServices1
3. Click User Profiles and Properties
4. Under User Profile Properties, click Add Profile Property
5. Fill in the required data and click OK
Now that we know that SharePoint accepts data from external sources and that it stores individual user values in user profile properties, it’s time to put the two together and find out how to store user data in profile properties from external data sources. This is the topic for part two of this post: Getting/Storing user data from external sources.
Labels: .NET, Authentication, SharePoint, testing, web development
Tuesday, October 23, 2007
Easy NTLM Authentication in Java Web Apps
A common requirement of web apps on corporate Intranets is NTLM HTTP authentication. This allows a web browser to automatically login by providing the user's network password, without the user having to manually go through a login dialog.
NTLM authentication is a staple feature of Windows-only IIS, but what if you want to offer NTLM authentication from a web server hosted on a Linux machine?
Recently I used the jCIFS NTLM Authentication module (http://jcifs.samba.org/src/docs/ntlmhttpauth.html). Literally all I had to do was drop a .jar file into the lib/ directory of my Java web app and copy-paste some options into my web.xml file. In minutes, my web app was authenticating users' NT credentials against the network's domain controller, and logging them in automatically.
The source code is open and seems easily editable, which is a good thing because it the NTLM authentication is pretty basic. For example, if a browser doesn't provide correct NT credentials, by default the web app will just keep prompting for credentials ad infinitum. I should be able to go in there and code a limited number of retries.
NTLM authentication is a staple feature of Windows-only IIS, but what if you want to offer NTLM authentication from a web server hosted on a Linux machine?
Recently I used the jCIFS NTLM Authentication module (http://jcifs.samba.org/src/docs/ntlmhttpauth.html). Literally all I had to do was drop a .jar file into the lib/ directory of my Java web app and copy-paste some options into my web.xml file. In minutes, my web app was authenticating users' NT credentials against the network's domain controller, and logging them in automatically.
The source code is open and seems easily editable, which is a good thing because it the NTLM authentication is pretty basic. For example, if a browser doesn't provide correct NT credentials, by default the web app will just keep prompting for credentials ad infinitum. I should be able to go in there and code a limited number of retries.
Labels: Authentication, JCIFS, NTLM, Single sign-on
