osuser / docs / index.html

	  <i>Note that currently no download of osuser is available, as we feel the documentation is insufficient to merit a binary release.<br>
	  However, we do encourage you to download and build the source code via CVS. Hopefully a full 1.0 release will be available soon.</i>
		<h3>What is it?</h3>

		<p>OSUser is a module of the OpenSymphony framework designed to provide a simple to use API for user-management. This API provides the access to
		 the following functions:</p>

				The process of verifying that the user is whom they say they are.</p>
				<p><b>Access Control</b><br>
				Determining whether a user is allowed to perform a certain task.</p>
				Personal details and data associated with the user.</p>
				Allowing the underlying data to be modified.</p>

		<h3>Pluggable Providers</h3>

		<p>While the developer need only work with a few simple interfaces, behind the scenes OSUser dispatches requests to pluggable <code>Providers</code>
		 that are used to access data from a variety of sources. </p>

		<p>OSUser shall provide pre-written providers for popular user-management systems, such as relational databases, flat/XML files, LDAP,
		Unix/NT users, NIS, PAM, JAAS providers, and proprietary systems of common applications and servers such as Orion, WebLogic, Resin, Tomcat, JBoss,
		Jive, and Jetspeed. More importantly, OSUser makes it very easy to create providers to custom solutions (such as your internal customer database).
		OSUser is also supplied with its own fast and robust providers built with Enterprise JavaBeans.</p>

		<p>There are 3 types of providers that can be plugged into the system; <code>CredentialProviders</code>, <code>AccessProviders</code> and
		<code>ProfileProviders</code>. Each provider is responsible for one of the above functions listed. Management of data is built into each provider.</p>

		<p>Providers can be mixed and matched in a system. Different types of providers can cooperate with each other. This is particularly useful when one type
		 of data-store cannot store all of the appropriate data for a user-manager. For example, a system may check the credentials (username and password only)
		 of users based on an entry in a custom database yet store a users profile by using the OSUser Enterprise JavaBeans.</p>

		<p>Providers of the same type can be chained together in a sequence allowing many to reply to the same request. For example, a user's credentials may
		 be first checked against a custom database, then (if not found) checked against a user in the operating system.</p>

		<p>Providers may be <code>Immutable</code> meaning they are read only. For example, a CredentialProvider that checks if users exist in the underlying
		operating system should <b>not</b> be able to modify the information.</p>


		<p>OSUser also provides <code>Bridges</code>, which allow popular systems such as the applications and servers listed above to use OSUser as a custom
		provider. For example, you could build your user-management system using OSUser and then allow your application server to talk to your system when
		it needs to check a user's credentials.</p>




			<p>I had a website orientated around a central set of discussion forums which manages a few thousand users. The forums are powered by Jive
			(an open-source Java based forum built with Servlets and JSP tags).</p>

			<p>At a later date I decided to modify the site so my application server will take care of restricting access to the forums using features
			of the Servlet API (it was currently being done manually in JSP pages). My application server was Orion so I created an Orion specific UserManager.</p>

			<p>Soon after that I decided that a content management system was needed and that OSContent would be suitable. Only there was a problem - I wanted
			to make use of the forum system and user management system in OSContent, while still keeping my Jive based forums. Unfortunately each system had
			its own user-management system, meaning either my users had to signup to both systems or I had to ditch one of the systems. Neither option seemed



			<p>Having OSUser would have solved the problem. OSUser could be deployed on to the site, with suitable providers to access the underlying Jive data.
			 A Bridge for Orion would allow the Servlet engine to check credentials against this data. Finally, OSContent could be installed using our
			 existing OSUser system.</p>
Tip: Use camelCasing e.g. ProjME to search for