Bug#497584: ITP: cosign -- Web single sign-on for intranets
On Wed, Sep 10, 2008 at 06:15, Neil Williams <codehelp@debian.org> 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
Reply to: