Bug#497584: ITP: cosign -- Web single sign-on for intranets
On Wed, 2008-09-10 at 20:34 -0300, Martín Ferrari wrote: On Wed, Sep 10, 2008 at 06:15, Neil Williams [EMAIL PROTECTED] 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
Bug#497584: ITP: cosign -- Web single sign-on for intranets
On Wed, 2008-09-03 at 04:01 -0300, Martín Ferrari wrote: Description : Web single sign-on for intranets What's the difference between this and OpenId ? Why the focus on intranets? 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 ? Cosign includes an Apache module for authentication in distributed applications, CGI scripts tmo handle logon/logoff and a session tracking daemon. Is this smartcard based or hot-desking via bluetooth or something? i.e. a system that logs you off when you leave your desk and logs you back in when you're back from lunch? ;-) 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. 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? 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. 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. ;-) I'm confused about why users would want to trust cosign to keep all their weblogin usernames and passwords - unless those usernames and 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. 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. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Bug#497584: ITP: cosign -- Web single sign-on for intranets
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
Bug#497584: ITP: cosign -- Web single sign-on for intranets
Neil, On Tue, Sep 2, 2008 at 18:51, Neil Williams [EMAIL PROTECTED] wrote: Description : Web single sign-on for intranets What's the difference between this and OpenId ? Why the focus on intranets? 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. An open source project originally designed to provide a secure single (s/open source// ? - implied by licence?) Gah, I was tired and just copied text from the website :) Cosign includes an Apache module for authentication in distributed applications, CGI scripts tmo handle logon/logoff and a session tracking daemon. Is this smartcard based or hot-desking via bluetooth or something? i.e. a system that logs you off when you leave your desk and logs you back in when you're back from lunch? ;-) hehehehe. No, it only maintains the logged-on/off state, but doesn't know about your culinary habits :) How would you re-phrase that? Thanks, Tincho. -- Martín Ferrari -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497584: ITP: cosign -- Web single sign-on for intranets
Package: wnpp Severity: wishlist Owner: Martín Ferrari [EMAIL PROTECTED] * Package name: cosign Version : 2.1.0rc1 Upstream Author : The University of Michigan * URL : http://weblogin.org/ * License : MIT Programming Lang: C Description : Web single sign-on for intranets 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. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497584: ITP: cosign -- Web single sign-on for intranets
On Tue, 2008-09-02 at 18:09 -0300, Martín Ferrari wrote: Package: wnpp Severity: wishlist Owner: Martín Ferrari [EMAIL PROTECTED] * Package name: cosign Version : 2.1.0rc1 Upstream Author : The University of Michigan * URL : http://weblogin.org/ * License : MIT Programming Lang: C Description : Web single sign-on for intranets What's the difference between this and OpenId ? Why the focus on intranets? An open source project originally designed to provide a secure single (s/open source// ? - implied by licence?) 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. Is this smartcard based or hot-desking via bluetooth or something? i.e. a system that logs you off when you leave your desk and logs you back in when you're back from lunch? ;-) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
