DICE development projects - inf-unit

Unit:

Summary:

Add support and tools to Prometheus for managing multiple identities

What:

Prometheus was designed to support the management of multiple identities for users, e.g. in the KDC case somebody/admin, somebody/cron. The various parts need to be tied together to implement this. It should be possible to support:

Creation of additional identities for any entity
Creation of account objects (e.g. AFS pts) for identities
Users creating additional identities (of form 'user/something' themselves)
Distribution of keytabs

Why:

Multiple identities gives a way of separating a user's privileges. Also it allows for automation of authenticated access to resources (e.g. an identity with an AFS account and keytab allows authenticated file system access to be automated).

When:

This work has already been started, as part of prometheus development. This project ties all the loose ends together.

How:

Adding multiple identities support to prometheus involves the following work:

Ensure multiple identity and account objects are supported as planned in prometheus
Add support to AFS PTS conduit to create new accounts (with uid automatically allocated from range)
Add support to command-line 'theogony' tool to allow sysadmins to create identities and accounts
Add support to prometheus remctl interface for identity/account creation
Adapt password setting CGI or write a new one to use remctl interface for users to manage identities (create, set password)
Configure wallet to support distribution of keytabs for additional identities

Effort estimate:

4 weeks

Other:

Dependencies:

Risks:

Produce a talks.cam not-a-service for trialling

ascobie — Fri, 30 Aug 2013 16:06:42 +0000

Project ID:

292

Current stage:

2_Evaluation

Manager:

Unit:

Summary:

Produce a talks.cam trial service for disseminating information about School talks

What:

Install the talks.cam software (http://talks.cam.ac.uk/document/documentation) on a VM and configure to authenticate against DICE.

Why:

Iain Murray suggested this a few project periods ago.

"I won't rehash all of the advantages (please look at the docs). But advantages for us would include: 1) the webforms are nicer than plone and announcements and requesting abstracts from speakers are dealt with by the system. 2) people can subscribe to any mix of talk streams in their calendars, email, and RSS readers. 3) Any combination of lists can be listed on the system, or embedded in any webpage. The School could list all talks going on in informatics on the front display screen, the main website, etc.

The system was developed by the academics that first used it, and after going through a couple of versions it's very usable and has proved popular. Maybe ultimately this is a system that should be talks.ed for the whole University. But trialling it with a couple of institutes and then a whole School first seems sensible, and is how talks.cam developed in Cambridge."

We were going to put some effort into quickly putting it up, but it hadn't been ported to SL6. It looks like this has now been done, so perhaps worth spending a small amount of effort to get it going.

Effort estimate:

1 week

Other:

Dependencies:

Risks:

Infrastructure Internal Documentation review

alisond — Thu, 22 Aug 2013 09:48:32 +0000

Project ID:

282

Current stage:

Unit:

Summary:

Review of Inf Unit internal documentation

Other:

Dependencies: project 280

Risks:

Options for two-factor authentication

gdmr — Thu, 04 Apr 2013 13:07:02 +0000

Project ID:

279

Current stage:

4_Signoff

Manager:

idurkacz

Unit:

https://wiki.inf.ed.ac.uk/DICE/FinalProjectReport-279

Summary:

Examine the options for two-factor authentication.

What:

Stephen says: "It occurs to me that we should have project to examine the options for two-factor authentication. This could compare the methods of solving the problem (X509 versus OTP), and look at the various hardware devices available. It seems that some are very expensive but are likely to be much better supported, others will be really cheap but we would have to run extra services and potentially hack applications ourselves. I mentioned this to Alastair and he reckons this fits best as something led by the Inf Unit."

How:

Invite interested parties to specify more exactly what is required (and whether or not they have specific ideas on how any such things might be implemented.)
Synthesize possible requirements.
Depending on requirements, attempt to prototype something reasonable.

Final report URL:

Other:

Dependencies:

Risks:

OpenLDAP: DICE client configuration

boss — Fri, 25 Jan 2013 15:46:28 +0000

Project ID:

267

Current stage:

4_Signoff

Manager:

idurkacz

Unit:

https://wiki.inf.ed.ac.uk/DICE/FinalProjectReport-267

Summary:

Review of OpenLDAP DICE client configuration

What:

Description: Investigate the various options for the use of LDAP on our DICE client machines.

Deliverables: Report, with recommendations. Subsequent implementation if required.

Why:

Customer: All

Case statement:

The current configuration of OpenLDAP on our DICE client machines generally works well, but changes in OpenLDAP mean that it should now be reviewed:

Every DICE client runs its own LDAP server. There are historical reasons for that, but is it still necessary? Could we move to a more standard client-server model?
DICE clients use a locally developed pull synchronisation technology - slaprepl - for replication. It would probably be better to use more standard software for replication, if such exists and is reliable.
All clients replicate from the single LDAP master, and we sometimes see client-side replication failures. Replication could probably made more reliable by configuring client replication from our LDAP slaves rather than from the single master. In any case, such a change seems sensible for reasons of load-balancing and redundancy.
The current replication system has a latency of up to one hour on any client. It would be good to reduce that time.
Our possible use of features such as nslcd, nssov overlay, sssd, proxycaching, etc. should be investigated.

This project follows on from the stalled project 79.

When:

Status:

Timescales:

Priority:

Time: Four weeks

How:

Proposal:

Resources: OpenLDAP knowledge

Plan

Document the current state of OpenLDAP configuration on DICE clients, highlighting any problem areas.
Find out what alternative options are available to us.
Investigate options.
Produce report with recommendations.
Implement whatever is agreed as a result of the above.

Final report URL:

Other:

Dependencies:

Risks:

Changes implemented incorrectly have the potential to break every DICE client machine.

Milestones

Proposed date	Achieved date	Name	Description

OpenLDAP: investigate slapd-config

boss — Fri, 25 Jan 2013 15:46:28 +0000

Project ID:

266

Current stage:

Manager:

Unit:

What:

Description: Investigate and test slapd-config with a view to using it for our slapd configuration

Deliverables: Report initially. Following on, slapd configuration supplied by slapd-config

Why:

Customer: All

Case statement: For some time now, the recommended configuration for OpenLDAP has been
to provide slapd configuration using
slapd-config (i.e. storing
the configuration in ldap itself), rather than in slapd.conf. The
real difficulty with this may be incorporating it into LCFG. Support
for slapd.conf is scheduled to be dropped in openldap 2.5.

When:

Status:

Timescales:

Priority:

Time: Probably 2-4 weeks

How:

Proposal:

Resources: openldap knowledge

Plan: Initial plan (to be expanded)

Initial investigation into slapd-config (outside of LCFG)
Investigate adding support for slapd-config to lcfg-openldap
Test
Implement

Other:

Dependencies:

Risks: if openldap is unreliable, machines break.

Milestones

Proposed date	Achieved date	Name	Description

OpenLDAP: investigate mdb backend

boss — Fri, 25 Jan 2013 15:46:28 +0000

Project ID:

265

Current stage:

Manager:

Unit:

What:

Description: Investigate and test the new mdb backend with OpenLDAP, with a view to using it on servers/clients

Deliverables: Initially, report on openldap using mdb and recommendations. Following on, systems using mdb.

Why:

Customer: All

Case statement: It is highly likely that the recommended backend for use with OpenLDAP
will become mdb (see http://www.symas.com/mdb/). We have been using a
bdb backend for both servers and clients since we started using
OpenLDAP. We have done some informal testing with mdb, but need to
test it properly.

When:

Status:

Timescales:

Priority:

Time: Probably 2+ weeks, much time may be spent in leaving systems running

How:

Proposal:

Resources: openldap knowledge

Plan: Initial plan (to be expanded)

Add support for mdb config to lcfg-openldap
Run some test machines
Report success or otherwise
Implement

Other:

Dependencies: None

Risks: If openldap is unreliable, machines break.

Milestones

Proposed date	Achieved date	Name	Description

Investigate alternatives to our existing MIT kerberos authentication infrastruct

boss — Fri, 25 Jan 2013 15:46:27 +0000

Project ID:

260

Current stage:

3_Implementation

Manager:

gdmr

Unit:

What:

Description: Investigate the possibility of moving our KDC (and KCA) infrastructure from MIT kerberos to heimdal, and the implications thereof. Investigate the alternative possibility of outsourcing it to EASE.

Deliverables:

Produce a report on the pros and cons of sticking with MIT kerberos or migrating to heimdal, and on the pros and cons of outsourcing to EASE.

Make recommedations as to how we should proceed, and when we should next review the situation.

(Any actual migration would be done as a separate project.)

Why:

Customer: All

Case statement:

We adopted MIT kerberos by default when the DICE project started. heimdal is now definitely a viable alternative, and is being taken up by a number of large sites and distributions. We should take a proper look and make an informed decision rather than just carrying on blindly.

The alternative suggestion of outsourcing to EASE has also been made. On previous occasions we and IS have concluded that this wouldn't be a good idea, but as we haven't looked recently we should consider this option if we are reviewing our authentication infrastructure anyway.

When:

Status: To be added to the 2013T1 bundle.

Timescales: It should be possible to investigate and report within a T.

Priority:

Time: Estimate a couple of weeks to get sufficiently to grips with Heimdal and to work through the implications.

How:

Proposal: Investigate. Report.

Resources: If we migrated to heimdal we would expect to run on existing KDC hardware (or planned replacements). If we outsourced to EASE there might be resource implications which can't be specified at the outset but which would be reported on as part of the project.

Plan: Other large sites have migrated, so it should be possible to tap into existing tools and experience.

Other:

Dependencies:

Risks: Breaking authentication!

Milestones

Proposed date	Achieved date	Name	Description

Lifecycle code design

boss — Fri, 25 Jan 2013 15:46:27 +0000

Project ID:

262

Current stage:

3_Implementation

Manager:

Unit:

What:

Description: The prometheus system won't really be complete without being able to handle account lifecycle in an integrated manner. This project is to design the lifecycle system and sketch out the code changes which will be required. Implementation will take place in a separate project.

Deliverables: A design for the prometheus lifecycle code.

Why:

Customer: All

Case statement: Simon's lifecycle code seems to be irretrievably lost, so we need to start again.

When:

Status:

Timescales: Expect to produce a design and have it reviewed within a T.

Priority:

Time: 4 weeks? It really depends on how much of the code that we did get can be reused.

How:

Proposal:

Resources: Moose and prometheus expertise is likely to be the resource in shortest supply.

Plan: Link to prometheus lifecycle wiki detailing what we have in terms of design and code.

Stocktake: we did get some code and outline thoughts from Simon. Take a look at these to see what we can use.
Design
Publish the design to the CO community for review
Iterate...

Other:

Dependencies:

Risks: Producing a design which, if implemented, might cause widespread breakage.

Milestones

Proposed date	Achieved date	Name	Description

Multicast routing

boss — Fri, 25 Jan 2013 15:46:26 +0000

Project ID:

255

Current stage:

Manager:

gdmr

Unit: