Re: New Package Proposal: Enterprise A&A

On Wed, 15 Jan 2003 12:53:23 -0600 (CST) Tony Bibbs <tony@tonybibbs.com> wrote: > Sorry, I don't dispute they aim to solve the same problem (A&A). I don't > even dispute the fact there are structural difference...after all both > were developed without the knowledge of the other. I've only harped on > the two differentiators that if you compare my original post in this > thread to what is shown in the PEAR descriptor for LiveUSer which are a) > web-service based and b) designed from scratch to eventually support the > Liberty project. After hearing more about LiveUser, it seems that b) is > possible though it was never articulated as a goal. Also a) is possible > with LiveUser. Is that accurate? Well, if you look back in the list archives, you will see that support for RPC authentication (no matter if XML/RPC, SOAP, Liberty Alliance or even Microsoft Passport - they´ve all been mentioned) has always been a design goal. Yet, there wasn´t anyone contributing to the project with experience in that matter, which is about the only reason why it hasn´t been done yet. If I´d mention really everything that is theoretically possible with the package, the description would be pretty long - who´d want to read all that? ;-) > If these aren't merged I don't see a real need for one having a container > in one to support the other. If someone else creates one to suit that > purpose, great, but this should really be a 'this or that' or 'coke vs > pepsi' decision. If they are merged, great. Btw. I still think that Coke tastes better, but that probably doesn´t belong here ;-) Oh, I´m not speaking of Diet Coke, Cherry Coke or the like, of course ;-) > Also, some further discussion on permission management needs to be done > since both handle them differently. Which reminds me, I had asked for a > use case or two around permission management that may 'break' either or > both approaches...still waiting on that. I don´t think there is much that can break any of the approaches concept-wise, as you can always write new permission management classes for both packages. However, IMHO having group membership stored in the authentication data AND the permission data is not such a good idea. Is storing groups in the authentication provider optional or mandatory in your package? > We should first compare the requirements both systems and analyze them > against both system before we assume that the migration will be > A&A->LiveUser as opposed to LiveUser->A&A. I just want to give this the > due diligence it deserves. I can honestly say I'd be willing to move my > code into LiveUser granted that migration path makes the most sense. Please clarify what you mean by requirements - I take it you´re not talking about system requirements as this should be quite obvious? Regards, Markus -- Markus Wolff <wolff@21st.de>