On Wed, 2008-09-10 at 20:34 -0300, Martín Ferrari wrote: > On Wed, Sep 10, 2008 at 06:15, Neil Williams <codehelp@debian.org> wrote: > 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. OK, this is beginning to make some sense - squeezing this into the description is going to be a challenge. :-) > 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 Hmm, that page could do with a lot of simplification. > > 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 :) It is difficult to explain but if the description would contain little nuggets like "centrally handles authentication using tokens in a similar manner to kerberos" and then give a bit of detail about how it compares with those similar projects (the ones already in Debian). > > 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 :) True, but the description probably needs to give some hints about how it could be implemented. > > 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. That is what needs to be set out in the description - if that had been put in at the start (or even mentioned on the website), it would have saved a lot of confusion. > > 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. OK, so cosign is passing on existing authentication from one server to another within an intranet, sort of. I don't think I understand it sufficiently to rewrite the description but I think if you have set out the main points yourself, it just a bit of reorganising. The description should cover these basic ideas: 1. cosign is a system to handle authentication centrally, passing tokens around in the form of cookies, in a similar manner to kerberos. 2. 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. 3. it is 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. 4. You can compare it with bitcard (used in rt.cpan.org) or other similar projects, like Shibboleth, pubcookie, mod_auth_tkt and openSSO. The original description was: An open source project originally designed to provide a secure single sign-on web authentication system, with support for different authentication backends and fault tolerance by means of replicated servers. Cosign includes an Apache module for authentication in distributed applications, CGI scripts tmo handle logon/logoff and a session tracking daemon. The 4 points above can replace the old description completely, just reorganised a bit. Cosign is a system to centrally handle authentication, passing tokens around in the form of cookies, in a similar manner to kerberos. An Apache module is included to replace or complement existing authentication methods like basic auth. . Cosign uses a session cookie, which is not sent to the browser, and redirects you to the main weblogin page when a user is asked for credentials or given a new service-specific cookie if you already had authenticated there. (that bit needs to be reworded) . Cosign is useful when you can trust a central place to manage users (e.g. ldap, kerberos, nis, etc). Cosign doesn't keep the usernames and passwords, it just relies on any authentication scheme you want to use. . Cosign can be compared with bitcard (used in rt.cpan.org) or other similar projects, like Shibboleth, pubcookie, mod_auth_tkt and openSSO. Something like that. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part