You are here

Production Cosign Service

Project ID: 
3
Current stage: 
Manager: 
Unit: 
What: 

Description: Complete the introduction of the Cosign/WebLogin service to mostly-replace KX509.

Deliverables: A production Cosign and web login service configured and managed via LCFG. A test client service indicating usage. Documentation describing how
to Cosign-enable a service.

When: 

Status:

03/09/07
The cosign documentation has been updated, including the lcfg-cosign man page and the configuring clients page. A new page, containing a brief overview of the Informatics cosign service, has also been added.
03/09/07
Cosign now supports iFriend logins - see the iFriend project for more details. In short, this extends Cosign so it supports guest account authentication, using a KDC backend (rather than the MySQL database used by Cosign's 'friend' implementation).
03/09/07
The cosign component has been re-written to use the apacheconf component for web server configuration (it was previously configuring and shipping its own apache)
01/08/07
The cosign service has now been used for the development project website, used by computing staff only, for more than a month and has proved to be stable and robust in that time.
01/08/07
In testing, Cosign's replication hasn't shown itself to be completely reliable. it is described in the Cosign FAQ as "best effort", when replicating 'login', 'register' and 'logout' operations to other cosign servers. It is noticable, however, that replication is more reliable when the server is busy than when it has infrequent connections made to it. This suggests that replication may work better when the service is in full-use. One important factor is that, in the event of one of the two cosign servers going down, fallover to the other one seems to work smoothly - both where the initial ticket has been replicated and when it hasn't. The worst that should happen in this case is that someone would be asked to re-authenticate. Therefore, I consider the 2 cosign-server setup sufficiently reliable to be made into a production service, but would recommend that replication is monitored, to be re-investigated if it found to not work well enough. The smooth fallover to another server is the most important factor here, in persistence and reliability of service.
27/07/07
A document describing how to configure the client side of Cosign is available here.
1/05/07
As agreed at the last Development meeting, I have put back the 'Upgrade' milestone by a month and re-adjusted other milestones accordingly. I have also created a milestone for adding SPNEGO support to Cosign.
17/04/07
The milestone to upgrade cosign to the latest version has slipped somewhat - I had trouble getting cosign to work properly with the newest version, particularly with two-servers and using the existing LCFG set-up. I believe I now have this working and am incorporating the required changes into the cosign component and header files.
15/04/07
Following discussions within the inf-unit (and beyond) on how best to handle lightweight authentication, Simon has created a new project for this purpose.
04/04/07
Following discussions with Tim, we believe the "cosignFixSSL" milestone is complete.
29/03/07
At a recent inf-unit meeting we decided not to support kx509 in cosign, in favour of SPNEGO. This is largely due to the lack of credential delegation using kx509. Simon has patches which add SPNEGO support to cosign.
28/03/07
A further security vulnerability has been discovered in cosign - the latest version is now 2.0.2a, which we will be using.
01/03/07
All milestones have been revised as part of the project handover from George to Toby.
01/03/07
Following handover of the Cosign project from George, I have spent some time in attempting to get the newest version of Cosign (2.0.1) working with the current set-up. This has been fairly unsuccessful, so I am returning to version 1.8.5, which we know to be working. Familiarisation with a working service will be beneficial in debugging problems with the newer version.
01/03/07
A security hole has been discovered in Cosign, requiring us to either upgrade to the newest 1.x or 2.x version (or patch 1.8.5).
06/02/07
All milestones dates revised, due to shortage of inf-unit effort.

Timescales: Originally planned for end of January 2006 this has slipped badly. No external time pressure.

Priority: Was already a high priority, it should be even more so now it has slipped so much.

Time: Two full time weeks.

How: 

Proposal: Provide two servers running Cosign. The servers should replicate between each other using Monster. One server to be in the central area and one to be at JCMB. Setup the service to distribute load between the servers using DNS round robin. Allow KX509 authenticated clients to pass through. Create suitable LCFG components, headers and configuration to manage the service. Provide the web login service (for connections not already authenticated). Provide a sample client service (that was using KX509 previously). Provide documentation for using Cosign. Do sufficient robustness testing to qualify as a production service.

Resources:

Suitable server hardware has already been purchased and deployed. UPS provision
is by piggy-backing on existing kit.

Cosign, KX509, SSL certificate, Apache and LCFG expertise is required.

Plan:

Note that much of this project is already complete, so the following
is only documenting the remaining steps.

  1. Upgrade to latest version of Cosign. Note that this may have a bearing on some of the following steps.
  2. Fix the SSL certificate redirect/alias problem - this may require patching the original Cosign source.
  3. Implement a dynamic services list (via LCFG by extending the existing spanning map).
  4. Create a documentation web page, including sample configuration for adding a Cosign service (in the profile this is achieved with a header but Apache configutation is also required). Include links to the existing sample
    service.
  5. Do fallover tests and check replication is working (logs suggest it is but testing what happens when one server breaks has not been done yet).
  6. Rebrand the Login/Services web pages for Informatics.
  7. Advertise within COs and do some further robustness testing.
  8. Convert a suitable live service to Cosign and evaluate.
Other: 

Dependencies: This project has no dependencies. Some projects may be waiting on a production Cosign service.

Risks:

Need to be careful with the security of the servers.

Need to ensure service is robust before wider deployment/usage.

Additional work is needed to support Cosign for all services.

Some user
re-training work (and altered documentation) required.

URL: https://wiki.inf.ed.ac.uk/DICE/CosignProject

Milestones

Proposed date Achieved date Name Description
2007-10-11 2007-08-15 production serv Production service (including spnego changes to firefox config for all DICE users)
2007-04-27 2007-05-01 Upgrade Test version of latest cosign software running, with lcfg-cosign changes as necessary, but uncustomised.
2007-04-04 2007-05-01 cosignFixSSL Fix the SSL certificate redirect/alias problem - this may require patching the original Cosign source.
2007-06-04 2007-05-15 cosignDynServ Implement a dynamic services list (via LCFG by extending the existing spanning map).
2007-07-27 2007-08-01 cosignDoc Create a documentation web page, including sample configuration for adding a Cosign service (in the profile this is achieved with a header but Apache configutation is also required). Include links to the existing sample service.
2007-07-30 2007-08-01 cosignProjTesti Do fallover tests and check replication is working (logs suggest it is but testing what happens when one server breaks has not been done yet).
2007-08-01 2007-08-01 cosignCOTesting Advertise within COs and do some further robustness testing.
2007-03-16 2007-03-15 cosignFamiliar Familiarise with working Cosign set-up using version 1.8.5
2007-06-21 2007-06-01 cosignCustom Customise appearance for Informatics
2007-06-21 2007-06-15 cosignSPNEGO Add SPNEGO support to Cosign