RE: [PEAR] Re: Singe Sign On

[[snip]] > Another question is what about user profiles? for example let's assume > we want to create a dating service. ( dating.example.com) Profiles for > such sites are huge, ( height, eyes, ...etc ) so I suppose I need to > store the profiles on the dating service database. so, SSO will only > store usernames/passwords But the problem is that what if two services > are storing the NAME. then I don;t want to have redundant copies of > that... oh, things are getting complex :D > > yeap - you usually end up with some duplication - I used SOAP to send stuff back and forth occasionally, > otherwise relying on the browser redirect process, with some variable flying off the end of the redirects. > > Regards > Alan I have seen SSO solutions that don't do this. It doesn't make a lot of sense to sign on in one place, and then ship that username and password all over creation to log into every single service you wish to connect to. Doesn't sound very safe either. SSO involves two parts - authentication and authorization. Once you authenticate a person and agree that the person logging in is who he says he is, you then have to check the authorization for what this person can do. Which apps can he use, which services can he access. It is this authorization that you should pass around to the other apps/services. This process removes duplication of data - all of your user profiles and permissions schema live in one place, and the user truly only signs on in one place. All of the other apps trust that the authentication is valid. If you are building a new system, you could probably implement this with relative ease using SOAP. Like I said though, I don't know which services and applications you are trying to use, and if you could even implement something like what I propose above. -Erich-