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