Re: SourceID.Net - SqlFederationhandler.
David Waite <[email protected]> Thu, 28 Aug 2003 10:47:01 -0600
| Newsgroups | gmane.comp.sourceid.sso.devel |
|---|---|
| Message-ID | <[email protected]> |
Cholan NSamy wrote: > Hi all, > > I have deployed the sourceID.net version0.3 in windows 2003, I’m > working on sp-sample and idp-sample available along with the download. > > I have trying to understand how this SqlFederationHandler works. > > In that the table account_federations doesn’t stores the password in it. > > I am able to login with any password. Can any one help me out to clear > my doubts? > I think this is a misunderstanding on what the Federation handlers do; let me know if this helps. This is correct behavior; the interface does not handle local authentication; it handles storing and retrieving account-linking information for the user with other federated sites. You could say that Liberty-enabled 'Service Provider' (SP) sites have two separate authentication mechanisms: - The user logging directly into the SP with a username/password credentials - A trusted 'Identity Provider' (IDP) asserts that a user has the associated identity. The Identity Provider asserts this by using a unique key[1] value associated with the user by the account linking. The IDP and SP both know the user by this key, but do not share any user data by default, including the account name(s) of the user on the two web sites. The IFederationHandler interface allows a website designer to choose how these keys are persisted. It does not look up other information associated with the identity, or provide for checking the local SP login. By not requiring this interface to support password lookup for local authentication, it allows greater flexability for local authentication methods (such as kerberos, SSPI, x.509 client certificates...). [1] Technical detail: This key is actually a pair of name identifiers; the value is actually allowed to be different depending on if the SP is talking to the IDP, or the IDP is talking to the SP. I just describe the whole thing as a single 'key' to simplify the above description. > 1. When federating, don’t we have to store the password? If yes how > to store that? Because account_federations table doesn’t have > that provision to store the password data. > 2. I get a error when loging out. The error message is > > "Logout request received for a NameIdentifier which does not match the > current user session" > > sess[Constants.Session.UserId] -- error: object 'sess' doesn't have an > indexer > Hmm, that error is odd - looks like there is no session data in ASP.NET associated with the user. Can you send me a stacktrace of the error, or file a bug? Does it always fail on logout? -David Waite