Hi,
Please consider two scenarious of claims forms auth given bellow. My intent is to look for a way to avoid writing too much claims code and given that claims identity passes through everywhere like BCS etc.
Scenario A. Having to authenticate with more than password and user id fields - I pretty much have solution for this described later, any suggestions welcome.
Scenarious B . Having to authenticate using 2 forms authentication providers in same site (without extending) - consider the login page with two login controls each invloking separate provider. Note Settings of auth providers will allow just one form
authentication provider. This is the scenario for which I need to do more testing or need inputs.
I am not talking about the SAML or trusted provider, just the forms auth in claims mode ( which is the only possible mode for forms auth ) and I am not talking about setting forms claim auth using default ValidateUser implementation which has 2 params,
it works without any issues.
I think SPClaimsAuthProvider override (e.g. http://blogs.technet.com/b/speschka/archive/2010/03/13/writing-a-custom-claims-provider-for-sharepoint-2010-part-1.aspx as this is not case of claims augmentation or claims picking - picking although is there
in later part of scenario B) override is not a solution for these scenarios but again need thoughts, may be I am wrong.
------------------------------------------------------------------------------------------------------------------------------------------
Scenario A -
In 2007 it uses asp.net forms authentication and login control which then calls membership provider and sets the forms identity.
Many times the login control needs to capture more than password and id like dob etc. In this case validateuser method gets overloaded to accept additional params and custom login control calls the overload of validateuser, creates cookie, sets identity. End
of story in case of 2007.
In 2010, login controls authentication is overtaken by the formsSignInPage (defualt ootb sign in page) which hookes the authenticate event and gathers the username password and passes on to federation provider which then goes all down to STS , STS loads
the formsauthentication provider and calls the ValidateUser and yes IT WOULD BE default implementation i.e. the one which accepts username and password. Unless you want to go ahead and modify this chain of calls which seems quite complex and error prone route
to be ,unless there is a pluggable component to hook in, it would be good idea to stick to default Validate with 2 parameters and let 2010 take care of rest of things.
But then how do we pass the extra bits like DoB etc to membership provider?
one solution I have thought about this is looking at password as composite password which consists of password string, dob and any other fields which basically it is really.
so derive from ootb login control, add your extra controls, gather info and put it may be as comma separated or xml and override Password propoerty and return it as password.
Inside your membership provider, you break the password string and use it whatever way you can.
So we create a formsSignPage derived application page as custom login page , modify the content to refer to custom login (derived from ootb login control) thats it.
I have done this in a proptotype and there are no problems, it works. We just have one forms authentication providerin this scenario so rest of the relevant methods like getAllRoles work fine. My testing is fairly limited hence any thoughts would be welcome
although.
----------------------------------------------------------------------------------------------------------------------------------------------------------
Scenario B
This is extension of A where I want to put two login controls on a single page (off course same site) and depending on choice of user, authenticate using appropriate mechanism. - quite complex requirement but still want to explore opportunity to avoid custom
code as much as possible.
In this case the custom forms authentication provider we define in the authentication provider ( note there can just be one forms auth provider we can specify) settings, acts like a master provider and gets the userid and composite passoword and the composite
password contains additional info which is target memberhip provider to call.
So far so good, authentication works but what about other role provider methods like GetAllRoles or GetUserRoles how would these methods know which one to call from the master role provider?
This is bit I am thinking about...
Could we possibly store the actual membership provider somewhere when the authenticate method is called so that it can be used in subsequent calls?
But then what about the picker , override SPClaimProvider to provide the heirarchy support and add nodes which specifies which specific provider to call within the master provider This search again would set a property in the session which would be picked
up by the master provider to call appropriate method.else in the master roles provider we search all .
So although we write some code here but its limited to adding heirachy support and some tricks in membership and role provider, we do not touch identity framework at all and framework always would end up calling with master provider default interface methods.
Scenario B is something I need thoughts on.
Regards
Yogesh Pawar
