Introduction
Many enterprise IT environments use Netegrity SiteMinder (hereafter called SiteMinder) to secure Web applications and servers. When customers decide to move to MS SharePoint 2007 (MOSS), they want to continue to use SiteMinder for their existing Web environment, and also as the authentication mechanism for their portal.
This article is an example of the implementation of the solution that allows using the SiteMinder authentication with WSS 3.0.
The key technical points of the solution:
1. SiteMinder authentication.
2. FBA (Form Based Authentications) for SharePoint applications.
3. Custom login form.
4. Custom membership and role providers.
SiteMinder authentication
The SiteMinder authentication is used for single sign on (SSO) functionality. Once SiteMinder authenticates a user it adds a special HTTP header with the user name to each HTTP request. SiteMinder can also create an authentication cookie that can be used if you want client software integration, for example, if you want to modify a document from a document library, using MS Word.
Since the SiteMinder authenticates users, the SharePoint authentication can be, and should be bypassed, we trust that the user is already authenticated and her name is contained in the HTTP header. The custom login form pulls the UserID from the HTTP header, creates the authentication token and redirects the request to the destination page. The trick is to make the SharePoint framework to authorize (or deny) the authenticated user correctly. To resolve users and role names the SharePoint framework has to use custom membership and role providers.
FBA (Form Based Authentications) and custom login form.
Since we are going to use the custom authentication mechanism (not Windows authentication) we have to use the Form Based Authentication. Our form shouldn’t have any UI, and user shouldn’t even be aware that the form is called.
The FBA has to be set up on the SharePoint Central Administration website. After opening the site go to: Application management->application security->authentication providers
At this point make sure that you are changing the right SharePoint application, the application URL is displayed at the upper-right corner of the page.
When you see the authentication type for your application (it’s windows by default) click “Default” and you will be navigated to the “Edit authentication” page.
On this page you can set up the Form Based authentication and the membership and role providers.
If you want to be able to edit documents from document libraries using MS Office software, don’t forget to click the “client software integration” radio-button
After you set up the FBA authentication for a SharePoint application, the central administration web site changes the web.config file of the SharePoint application. It sets up the authentication to “Forms” and loginURL to _layouts\logon.aspx. In the modified web.config file of the SharePoint application you will see something like this:
Many enterprise IT environments use Netegrity SiteMinder (hereafter called SiteMinder) to secure Web applications and servers. When customers decide to move to MS SharePoint 2007 (MOSS), they want to continue to use SiteMinder for their existing Web environment, and also as the authentication mechanism for their portal.
This article is an example of the implementation of the solution that allows using the SiteMinder authentication with WSS 3.0.
The key technical points of the solution:
1. SiteMinder authentication.
2. FBA (Form Based Authentications) for SharePoint applications.
3. Custom login form.
4. Custom membership and role providers.
SiteMinder authentication
The SiteMinder authentication is used for single sign on (SSO) functionality. Once SiteMinder authenticates a user it adds a special HTTP header with the user name to each HTTP request. SiteMinder can also create an authentication cookie that can be used if you want client software integration, for example, if you want to modify a document from a document library, using MS Word.
Since the SiteMinder authenticates users, the SharePoint authentication can be, and should be bypassed, we trust that the user is already authenticated and her name is contained in the HTTP header. The custom login form pulls the UserID from the HTTP header, creates the authentication token and redirects the request to the destination page. The trick is to make the SharePoint framework to authorize (or deny) the authenticated user correctly. To resolve users and role names the SharePoint framework has to use custom membership and role providers.
FBA (Form Based Authentications) and custom login form.
Since we are going to use the custom authentication mechanism (not Windows authentication) we have to use the Form Based Authentication. Our form shouldn’t have any UI, and user shouldn’t even be aware that the form is called.
The FBA has to be set up on the SharePoint Central Administration website. After opening the site go to: Application management->application security->authentication providers
At this point make sure that you are changing the right SharePoint application, the application URL is displayed at the upper-right corner of the page.
When you see the authentication type for your application (it’s windows by default) click “Default” and you will be navigated to the “Edit authentication” page.
On this page you can set up the Form Based authentication and the membership and role providers.
If you want to be able to edit documents from document libraries using MS Office software, don’t forget to click the “client software integration” radio-button
After you set up the FBA authentication for a SharePoint application, the central administration web site changes the web.config file of the SharePoint application. It sets up the authentication to “Forms” and loginURL to _layouts\logon.aspx. In the modified web.config file of the SharePoint application you will see something like this:
More Here
Courtesy:http://mosssiteminderauthentication.blogspot.com/