On Wed, Sep 10, 2008 at 06:15, Neil Williams <[EMAIL PROTECTED]> wrote:
>> OpenId is decentralized and open. This is targeted to a diffrent >> public (from what I understand), and the authentication is handled by >> a single source. > Single Point of Failure ? No quite, it provides some fault-tolerance. Anyway, you're missing the point that this is targeted at a different audience. For example, I've just deployed cosign at my job, to have SSO in internal webapps that can't use something open to the world like openid. >> hehehehe. No, it only maintains the logged-on/off state, but doesn't >> know about your culinary habits :) How would you re-phrase that? > > I'm still not quite sure I understand what cosign is trying to do - is > it offering an alternative to the existing Apache authentication systems > like .htaccess etc.? Some kind of frontend to other website > authentication or some kind of cache that stores your username and > password for next time? Does this only work with particular websites > that have configured their authentication protocols to work with cosign > (aka OpenID) or can it masquerade as the authentication protocol for > unmodified websites, in which case it would seem to be at least storing > the authentication details used by those websites. it works as a authentication module in apache, replacing/complementing basic auth and the such. It uses a session cookie, but you don't have it, it redirects you to the main weblogin page when you're asked for credentials or given a new service-specific cookie if you already had authenticated there. I think the mechanism is well explained here: http://weblogin.org/overview.html > I've looked at http://weblogin.org/overview.html but I'm not sure I > understand it. I'm confused about whether this is some kind of portal > for use where internet access is charged / time-limited (like an > internet cafe or hotel) or some kind of network filter that either > blocks or allows traffic to certain websites. I'm also concerned about > *why* a system would be configured to store the web logins of all users > in a single location. Or is this some kind of "keep-me-logged-in" > service like stay-alive or similar that keeps pinging the login to > prevent timeouts? It's no filter or portal. It's just a system to handle authentication centrally passing tokens around in the form of cookies, I think it can be paralleled to kerberos in that idea. You can compare it with bitcard (used in rt.cpan.org) or other similar projects, like Shibboleth, pubcookie, mod_auth_tkt and openSSO. It's difficult to explain, I guess all those websites will do a better job :) > If it is trying to be something like OpenId for intranets, then it > shouldn't get involved in the cookies themselves, the sites requesting > authentication need to be modified to support the cosign method, without > revealing the login details of the users. I can't work out whether it is > doing that or not. This requires no modification to applications that were already relying on apache authentication. In any case I think it's not me or you who decide how it should be implemented :) > The website is completely unhelpful in deciding what this package is > trying to do and what problems it is either trying to solve or likely to > generate. The wiki overview is just a rehash of the website overview > that is no clearer, at least to me. I hope this package will come with > some clear documentation. ;-) Yes, the documentation is crap. I'm trying to work on that, but there's no clear license on the current web docs, so I cannot work with them as a base ATM. > I'm confused about why users would want to trust cosign to keep all > their weblogin usernames and passwords - unless those usernames and err... I don't understand you :) This is thought for places when you can trust a central place to manage users (think ldap, kerberos, nis, etc), and in any case, cosign doesn't keep the usernames and passwords, it just relies on any authentication scheme you want to use. > passwords are part of the same intranet that uses cosign at which point > it would seem bizarre that to fix the various login problems of a > variety of websites inside an intranet, the admin would add another > login that knows all the login details of all the users. Well, that's exactly the point, you have 20 websites, each with its own htaccess file, and you as a sysadmin hate that. You can configure ldap/krb/etc and make apache authenticate against that on _each_ server, which will solve the single password issue, but the users still have to enter user/pass each time, also you need to protect the channel because the passwords are sent in the clear. > I can't help thinking that cosign is a solution looking for a problem. > Maybe open this up to -devel where there are people with more experience > of network-admin/authentication/intranet issues. That's ok to me, if you want. Not sure if anything productive can be taken out of the common thread you see in -devel. -- Martín Ferrari -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]