I created custom login page for FBA access (SP 2010). In related custom code i inherit Microsoft.SharePoint.IdentityModel.Pages.FormsSignInPage class.

Problem: I would like to login in sharepoint with my "hardcoded" user (e.g. "i:0#.w|domainxxx\userxxx")(that is also my win account) but when I call "FormsAuthentication.RedirectFromLoginPage (hardcoded_user,false)" i got error: "System.NullReferenceException: Object reference not set to an instance of an object". Why I can't be redirected to SP ?!?

Do I need to create some SP token, or what. As it seems to me SP can't redirect to my return url for some reason but I'm not sure is that problem or something else. Please any suggestion!!!

------UPDATE ------- I need to handle on login page two kind of possible users. Intranet (AD) and web users which are already authenticated on some custom SSO which if user is authenticated make request to my SP site with appropriate token. If custom token exist I need to create mappings to SP user (by email for examle)based on token data and login that user to SP otherwise i need to create new user/user profile from code based on data from token.

Does somebody have some link or concrete info which can be useful to me. ???

2 Answers 2


you nearly answered your own question. You cannot make this happen simply by changing the login page. One choice is to create your own Membership Provider, but I do not advise doing that based on your described requirements. The second would be to try and understand how Claims-based Identity works and "impersonate" using that methodology.


You should review this video from PDC'09 on SharePoint 2010 and WIF. I think it will highlight how SharePoint identity and authentication has changed since the 2007 release.

  • I will view video, but isn't it possible that login page be just some kind of handler without controls? I would like to handle login logic based of request params. If params (e.g. custom token containing user email*) like * exist in list of properties of some AD user - then I get that user username via membership provider(provider.FindUsersByEmail) and passed that to sharepoint as login information. That would be simple and awesome. Can that be done?
    – trip
    Jun 27, 2011 at 13:38
  • It is possible what you are describing CAN be done, but, from experience, you cannot handle Claims-based Identity scenarios the same way you've handle FBA in the past. Your best shot at "short circuiting" the login page, is to get the token that gets passed in through the Authentication header once you log in the "right way" and add that token to new requests when you want to impersonate. Claims-based boils down to a toke in the HTTP Requests Authentication header. Jun 27, 2011 at 13:48
  • Hi Glen. Please look at question update. Video was good but it doesn't help me too much in my case. I need more concrete information. This is too abstract for now.
    – trip
    Jun 28, 2011 at 8:28

I suggest you reflect Microsoft.SharePoint.IdentityModel.Pages.FormsSignInPage, so that you can see how the page handles the different events of the login control. If you're going to do some major customizations to the page, you may just want to create the page from scratch and forget about inheriting from FromsSignInPage.

The real secret to logging in with FBA in SP2010 is this line of code:

Microsoft.SharePoint.IdentityModel.SPClaimsUtility.AuthenticateFormsUser(new Uri(SPContext.Current.Web.Url), username, password);

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.